Cardiac arrest event (code) support system, equipment and methdologies providing recordation, documentation, analysis, feedback and post event processing

ABSTRACT

Disclosed embodiments are directed at providing a cardiac arrest event support system, equipment and methodologies that enable recordation, documentation, real time analysis, feedback to personnel treating a victim of the event and post event processing to support objective documentation and post event processing (e.g., inventory, billing, etc.).

CROSS-REFERENCE TO RELATED APPLICATION(S)

The present application claims the benefit of priority to ProvisionalPatent Application No. 61/824,423 filed May 17, 2013, the contents ofwhich are incorporated herein by reference in their entirety.

COMPUTER PROGRAM LISTING APPENDIX

The present application incorporates the concurrently filed text file,entitled “Exemplary_Software_Implementation.txt,” (programmed inMicrosoft® Access and provided in ASCII format).

FIELD OF THE INVENTION

Disclosed embodiments are directed, generally, to a system, equipmentand methodologies for documenting, analyzing, and processing dataassociated with a cardiac arrest's events.

DESCRIPTION OF THE RELATED ART

Sudden Cardiac Arrest (SCA) is second only to all cancer deaths combinedas a cause of death in the United States. Each year between 300,000 and450,000 persons die because their hearts abruptly stop pumping. Theirdeath is sudden and without warning—they are alive one moment and asecond later they've lost consciousness and collapse. They cannot callfor help, and they die within minutes at the very same location where,moments before, they were standing or sitting or lying. Their lives areliterally in the hands of whoever is present when and where theycollapse. In the vast majority of cases this is a spouse, a neighbor ora stranger—individuals with the least amount of expertise in how tomanage victims of SCA—and time is critical. In almost all such arrests,trained rescuers are summoned to complete the resuscitation process.

SUMMARY

To address this significant risk, disclosed embodiments have beendeveloped and designed to provide an objective appraisal of the overallmanagement of a cardiac arrest event. The following explanation presentsa simplified summary in order to provide a basic understanding of someaspects of various embodiments. The summary is not an extensive overviewand is neither intended to identify key or critical elements nor todelineate the scope of the disclosed invention. The following summarymerely presents some concepts of the invention in a simplified form as aprelude to the more detailed description below.

Disclosed embodiments are directed at providing a cardiac arrest eventsupport system, equipment and methodologies that enable recordation,documentation, real time objective analysis, immediately availablefeedback to trained personnel treating a victim of the event and postevent processing to support objective documentation and post eventprocessing (e.g., billing).

Disclosed embodiments are directed to enabling the ability to record andanalyze the activities performed when treating an individual (real orsimulated) with a cardiac arrest; and to present the results of thatanalysis for immediate feedback to the involved practitioners.

In accordance with at least one embodiment, a system and equipment areprovided that enable real-time feedback for personnel responding tocardiac arrest while an arrest is ongoing.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention and the utilitythereof may be acquired by referring to the following description inconsideration of the accompanying drawings, in which like referencenumbers indicate like features, and wherein:

FIG. 1 illustrates an example of one hardware configuration that may beutilized to provide the disclosed embodiment functionality disclosedherein.

FIG. 2 illustrates one example of a form used to arrange the tasks on agrid in the GUI provided in accordance with at least one disclosedembodiment.

FIG. 3 includes a depiction of a screen shot which is exemplary of theGUI displayed on the equipment during a cardiac arrest event and what aRecorder might see when documenting Code tasks during that event.

FIG. 4 illustrates one example of an introduction screen for creatingnew Codes in accordance with at least one disclosed embodiment.

FIGS. 4A-4F are exemplary illustrations of the functionality availableto Administrators for developing Codes using the system provided inaccordance with at least one disclosed embodiment.

FIG. 5 illustrates another example of the Code Development screen(s)provided in accordance with the disclosed embodiments.

FIGS. 6 and 7 are exemplary illustrations of the various options for howa screen may be organized around categories.

FIG. 8 is an exemplary illustration of how a word is selected, and itscharacteristics can be modified including, the name displayed on thegrid, for example, how it fits into the task grid's icon, thedescription that appears in reports, a phrase used to describe the wordto voice recognition logic utilized in the system, the McMAID category,a drop-down list displayed, and/or whether it has billable eventsassociated with it.

FIG. 9 illustrates details regarding when adding words, whereinduplicates may not be allowed and deletions may only be allowed if anevent/word has not been utilized in an archived Code.

FIG. 10 provides an illustration of how synonyms may be utilized inaccordance with the disclosed embodiments.

FIG. 11 provides an example of a Code Development screen of the GUIdesigned in accordance with the disclosed embodiments.

FIG. 12, illustrates the structural configuration and logical componentsand relationship of components of at least one Main Menu screen that maybe utilized by two types of users, whose access to the functionality ofthe system and equipment differ based on the their roles.

FIGS. 13A-13B are exemplary illustrations of Main Menu screen(s) orportions thereof provided in accordance with at least one embodiment.

FIG. 14 illustrates the structural configuration and logical componentsand relationship of components of a Code Recordation screen.

FIG. 15 is an exemplary illustration of a system code development (orportions thereof) for developing additional system functionality.

FIGS. 16 and 18 illustrate the structural configuration and logicalcomponents and relationship of components of a Code Recordation screen.

FIGS. 17 and 19-29 are exemplary illustrations of a screen (or portionsthereof) that provide functionality associated with Code Recordation.

FIG. 30 shows a screen section that is only visible for Run ReportCodes.

FIGS. 31-39 are exemplary illustration of a screen (or portions thereof)that provide functionality associated with Code Recordation.

FIG. 40 illustrates the structural configuration and logical componentsand relationship of components of a Code Analysis screen for archivedCodes.

FIGS. 41-55 are exemplary illustrations of a screen (or portionsthereof) that provide functionality associated with Code Analysis.

FIG. 56 illustrates the structural configuration and logical componentsand relationship of components used to archive a Code.

FIGS. 57-58 is exemplary illustration of a screen (or portions thereof)that provide functionality associated with archiving a Code.

FIG. 59 is exemplary illustration of a screen (or portions thereof) thatprovide functionality associated with Pre-Code Set Specification.

FIGS. 60-63F are exemplary illustration of a screen (or portionsthereof) that provide functionality associated with Benchmarking.

FIGS. 64-65 illustrates the structural configuration and logicalcomponents and relationship of components used for system functionalitydevelopment.

FIGS. 66-69 are exemplary illustration of a screen (or portions thereof)that provide functionality associated with system functionalitydevelopment.

FIG. 70 illustrates the structural configuration and logical componentsand relationship of components used for organizing tasks on a task grid.

FIGS. 71-73 are exemplary illustration of a screen (or portions thereof)that provide functionality associated with task grid organization.

DETAILED DESCRIPTION

The description of disclosed embodiments is not intended to be limitingof the presently disclosed invention. To the contrary, those skilled inthe art should appreciate that there are numerous variations andequivalents that may be employed without departing from the scope of thepresent invention. Those equivalents and variations are intended to beencompassed by the present invention.

In the following description of various invention embodiments, referenceis made to the accompanying drawings, which form a part hereof, and inwhich is shown, by way of illustration, various embodiments in which theinvention may be practiced. It is to be understood that otherembodiments may be utilized and structural and functional modificationsmay be made without departing from the scope and spirit of the presentinvention.

Moreover, it should be understood that various connections are set forthbetween elements in the following description; however, theseconnections in general, and, unless otherwise specified, may be eitherdirect or indirect, either permanent or transitory, and either dedicatedor shared, and that this specification is not intended to be limiting inthis respect.

As explained above, in the precious moments available to save a person'slife, documentation is often the least important task on anyone's mind;and in many instances documentation is done retrospectively. Even whendone concurrently, documentation is seldom if ever utilized to discussand assess the quality of the resuscitation effort; rather it isperformed simply because documentation is a requirement. Thus, providingan accurate picture of the interventions and procedures employed and thetiming of those procedures during treatment is very often problematic.

The American Heart Association (AHA), beginning in the mid 1960's,developed programs to improve the care of SCA victims. The education oflaypersons, law officer and other first responders, Emergency MedicalService (EMS) providers and other medical personnel is performed usingtheir programs. Management guidelines are revised by internationallyrecognized experts on a regular basis, and these are then translatedinto programs and treatment protocols that are used in educationalefforts. Many millions have been trained and billions of dollars havebeen spent doing so. Resuscitation experts continue to teach the medicalcommunity what to do and why. Likewise, educational programs areresponsible for training the medical community how to do implement thesedirectives. The understanding of the physiologic derangements operantduring a cardiac arrest has improved tremendously over the years; andthe advice given to the medical community is scientifically based.

However, despite these extensive advancements, the survival rates forvictims of SCA have remained essentially unchanged over the last halfcentury. What we have done to date to improve survival does not seem tobe working: Improving scientifically base treatment guidelines on aregular basis and requiring providers to attend educational sessions ona regular required periodic basis has not accomplished what we expected.

Therefore, if improvement is possible, the medical community mustexamine the way we educate individuals who treat SCA victims. Areasonable starting point is to query what is it that thwarts theability to train competent responders. Indeed, education is crucial inthe process of developing competence; however, what occurs aftertraining is often more determinative of the degree and duration of aresponder's competence.

Considering the conventional education of potential responders, anobjective evaluation of performance for the resuscitation effort theyparticipated in is seldom performed. Whether the patient lives or dies,there is no impetus to challenge the assumption that the interventionsperformed were sufficient, appropriate and that treatment was optimal.In the absence of such feedback and education, providers are at risk ofcontinuing to deliver what may well be suboptimal care.

Likewise, the conventional training educational situation is similarlyhandicapped—subjective assessments of performance are fickle and oftenunreliable; individuals may pass a resuscitation training course and yetbe sub optimally prepared for a real-life event.

To address this shortcoming, and others, disclosed embodiments have beendeveloped and designed to provide an objective appraisal of the overallmanagement of a cardiac arrest. The following explanation presents asimplified summary in order to provide a basic understanding of someaspects of various disclosed embodiments.

Disclosed embodiments are directed to enabling the ability to record andanalyze the activities performed when treating an individual (real orsimulated) with a cardiac arrest; and to present the results of thatanalysis for immediate feedback to the involved practitioners. Inaccordance with at least one embodiment, a system and equipment areprovided that enable real-time feedback for personnel responding tocardiac arrest while an arrest is ongoing.

To provide an explanation of context and the deficiencies ofconventional approaches to cardiac arrest event training anddocumentation, it should be understood that, conventionally, therecording of actions performed during a cardiac arrest is most oftendone solely for the purpose of documentation. Moreover, the accuracy ofsuch documentation varies considerably—especially regarding the timingof events during a cardiac event. Most real-life cardiac events aredocumented using paper and pen; and the resulting documentation recordis either saved as written or it is simply used to create a morestructured report at a later time.

Conventionally, some computer devices are available that providedocumentation information (almost exclusively used in retrospectivereviews); and some even provide real time prompts regarding the qualityof resuscitation interventions. However, the scope of their informationand advice is limited to a small select subset of interventionsperformed.

To the contrary, the presently disclosed embodiments not only providethe ability to document an extensive set of events, in particular, withimproved timing accuracy, but also to provide immediate and objectivefeedback to those participating in treatment of the cardiac arrestevent, something that is not possible with conventional documentationtechnology or methodologies.

In accordance with disclosed embodiments, a system, equipment andmethodologies are provided that record event data and other relevantdata that enable objective analysis of a cardiac event and the careadministered to a victim of that cardiac event. Thus, to best understandthe functionality required to analyze cardiac arrest management, a briefexplanation of the various types of cardiac arrests is necessary.

Preliminarily, however, it should be understood that disclosedembodiments are explained with reference to cardiac arrest events, whichinclude events pertaining to the diagnosing, treatment and monitoring ofa patient having a cardiac arrest event. In the medical community, suchcardiac arrest events are also referred to colloquially as “codes.” Inthe presently disclosed description of the disclosed embodiments, theterm “Code” refers to a sequence of screens containing task and eventdata displayed on a Grid for selection by a user to record theoccurrence of such tasks and events. Thus, all types of cardiac arrestevents have a “Code” screen that displays events that may occur duringthe resuscitation process for a patient. As explained herein, theinventive system, equipment and methodologies may be used to record,analyze and generate reports regarding the tasks events that occurduring a Code.

Cardiac arrests, as defined within the disclosed embodiments, can becategorized into four code-types: Real, Mock, Testing or Run Report.

The first category, Real, pertains to Codes involving a real person in avariety of settings (e.g., a hospital ward, an emergency department, anambulance, etc.) where real time recording of relevant task performanceand events is possible and valuable. Events that preceded initialrecording can be memorialized; the retrospective timing of events (e.g.,in reports) can be adjusted to the actual time of the start of a Code.Most often the protocols that guide responders, which are used toanalyze performance, are known prior to a cardiac arrest event.

Therefore, in accordance with at least one disclosed embodiment, thesystem, equipment and methodologies may optionally enable the ability topre-program protocols by an Administrator. However, it should beunderstood that the disclosed embodiments may be functional to perform,recordation, analysis, feedback, training, and post event processingwithout reference to, or use of, protocol data.

An Administrator is a personnel member who may be tasked with and/ortrained to set up this cardiac event support system, equipment andmethodologies to address particular local needs. Thus, the Administratormay make modifications to treatment protocols, event descriptions (e.g.,words used in selecting and reporting events that have been recorded),and benchmarks (used to judge adequacy of performance), as explainedherein. Multiple sets of treatment pre-code events, protocols andbenchmarks may be developed by Administrators and may be specific tocodes developed for facilities and departments. Additionally, specificsets of pre-code events, treatment protocols and may be designated foruse when a Code is being recorded. The second code category, Mock code,pertains to scenarios that mimic a real Code but wherein recording ofall events is possible, including delays in arrival of equipment used totreat a cardiac arrest event. Protocols and equipment availability maybe known beforehand. Likewise, the onset of a Mock Code may be knownand, therefore, times (e.g., time stamps) recorded using the disclosedsystem, equipment and methodologies may not need to be adjusted (e.g.,appended, as discussed herein). In Mock Codes, recording of detailsregarding tasks and event in a cardiac arrest event may be performed inreal time.

The third code category, Testing, is similar to a Mock Code in that itis a structured training scenario, but all equipment is available; thus,arrival times for necessary equipment to treat the cardiac arrest eventmay not be tested. Likewise, onset of the cardiac arrest is known andrecording is real time.

The fourth code category, Run Report, pertains to the entry of data inretrospect from various sources that are record in a “Report”. Protocolsmay be assumed to exist.

As mentioned above, the disclosed embodiments, the system, equipment andmethodologies provided in accordance with the disclosed embodiments maybe utilized by an Administrator who is tasked with setting up thesystem, equipment and methodologies for use by other personnel, forexample, Recorders and Developers.

A Recorder is a personnel member who is tasked with both selecting acode-type at the time of a Code and performing the actual recording ofdata for the cardiac arrest event. A Recorder may only be required todecide the code-type that is to be processed prior to using theequipment to begin recording documentation. As explained herein,recording may be accomplished using a Graphical User Interface (GUI)that may include a plurality of touch screens that enable the Recorderto document task and event data during the cardiac arrest event.

Utilizing the computer interface that displays such a GUI, tasks may bepresented on a grid, as explained in detail herein, and can be recordedby the Recorder interacting with the displayed information to selectoptions, input information, etc., by interacting with the computerinterface physically, e.g., through mouse clicks, taps on a screen etc.,or through voice recognition technology.

Thus, it should be understood that, although the system may be providedin a number of different hardware contexts, the disclosed embodimentsmay be implemented (FIG. 1) using a generalized or special purposecomputer system 100 that may run software the provides the functionalitydisclosed herein. Thus, that system 100 may include one or more computeruser interfaces 105, with which personnel (e.g., Administrators,Recorders, and Developers) may interact via a Graphical User Interface(GUI) 110 and/or voice recognition technology (the technology also beingincorporated in software running on processor(s)) via at least onespeaker 115 (for receiving output from the system) and at least onemicrophone 120 (for providing input to the system). The systemfunctionality may be provided via software running on one or moreprocessors 125 that may be proximately incorporated into the one or morecomputers (e.g., via a computer Tablet or other computing device) or maybe running on processors 125 that may be remote from the userinterface(s) 105 but connected thereto for communication and control.Additionally, the software may be similarly stored in memory 130proximate or remote from the user interface(s) 105 but accessible fromthe user interface(s) 105; similarly, the data generated by the systemmay be archived or stored in memory 130 or another memory. That memory130 may be accessible by other post-event data processing systems 135,e.g., training software and systems, feedback systems, accreditationsystems, accounting systems, inventory systems, billing systems, etc.,to provided data to those systems for post cardiac event processing.

Using the equipment, event occurrence may be recorded in connection withtheir respective times (e.g., as indicated by a time stamp) to provideeffective recordation and documentation of a cardiac arrest event. Asexplained herein, time stamps generated by the system may be correctedif necessary; both during and after a preliminary analysis.

A program developer is a personnel member who may be called upon to makecustom adjustments to the displayed content in the GUI. It should beunderstood that the content displayed on the GUI, e.g., the display oftasks, is dynamic; thus, only those tasks reflecting the current stateof care for the cardiac event may be displayed using the GUI. Twoexamples of the content are shown in FIGS. 2-3.

As shown in FIG. 2, the content may include a task grid 200 thatincludes an array of icons that represent actions and events that occurduring a Code, i.e., tasks. The length of a task phrase displayed in theicons (i.e., a word) is limited by the space available on the iconsthemselves. Longer, more descriptive, phrases may be associated witheach word; such phrases may be used in lists of tasks performed invarious screens output on the GUI. As explained above, words and thephrases used to describe them may be customized by the programAdministrators.

As shown in FIG. 2, all of the tasks in 210 may be available forselection by a Recorder. There are no tasks assigned to the 215 icons.The grid 200 may also include an exit icon, which may be selected totrigger display of a higher order menu screen discussed herein. FIG. 2is a screen illustrating a form used to arrange the tasks on a grid inthe GUI provided on the system.

However, program logic limits the tasks displayed on the grid in acontext-sensitive manner. For example, in FIG. 3 no drugs are displayedbecause an intravenous access has not been established. This screen shotis exemplary of the GUI displayed on the equipment during a cardiacarrest event and what a Recorder might see when documenting Code tasksduring that event.

Table 1 below provides an illustrative example of the Words that may belisted in the icons that may be included in the GUI and the associatedcardiac arrest event task.

TABLE 1 ButtonName ReportName A Fib Rhythm: Atrial Fibrillation AllClear Cleared before Shocking Amio 150 Amiodarone 150 mg Amio 300Amiodarone 300 mg Analyz Rhythm Pause - Analyze Rhythm Apply LUCAS StartLUCAS application Apply O2 O2 Applied Apply Pads Apply Pads AssignsRoles Team Leader: Assigns Roles Asystole Rhythm: Asystole AtropineAtropine Bicarb Sodium Bicarbonate Calcium Calcium Call for Help Calledfor Help Charge Pause - Charging Charge Done Charge Completed CheckPulse Pause - Pulse Check Code Finished Code Phase Completed CodeTeamCodeTeam Arrives Crash Cart Crash Cart Arrived D50 D50 Dopamine DopamineDose Atropine Discussed Atropine Dosage EKG Done 12 Lead Performed EpiEpinephrine etCO2 Main etCO2 Mainstream Used etCO2 Side etCO2 SidestreamUsed Glucagon Glucagon Heard Page The Overhead Page was heardHypoThermia Discussed Hypothermia Is Captain Team Leader: Takes ChargeIV Done IV Running IV Failed IV Failed IV Started IV Started KetamineKetamine Know Is PNB PNB Recognized Knows ROSC ROSC Recognized Lab TestsDone Ordered Lab tests Leads On Okay Monitor Leads: AppropriatelyPositioned Lidocaine Lidocane Lost ROSC Lost ROSC LUCAS Failed LUCASFailed Manual Unit Using Manual Defibrillator Mark *** Mark ***Metronome Metronome Started Mg++ Magnesium Sulfate Mobitz 2 Rhythm:Mobitz Type 2 Monitor Here Monitor Arrived No Shock Pause - No Shockdelivered NonShockable Non-Shockable Rhythm O2 Sat Done O2 SatDetermined OPA OPA/NPA Inserted Other Airway Start Other Airwayinsertion Other Drugs Other Drug Other Reason Pause - Other ReasonPaceMaker Pacemaker Applied Pacer mA PaceMaker: mA Set Pacer RatePaceMaker: Rate Set Pads Failed Pads Failed Patency Patency CheckedPause 4 ET Pause for ET Insertion Ended Pause 4 ET Pause - ET InsertionPEA Rhythm: PEA Peek@Rhythm Pause - Peek at Rhythm Pulseless VT Rhythm:Pulseless Ventricular Tachycardia Put On Leads Monitor Leads: AppliedRead Rhythm Analyzes Rhythm ROSC Pause - ROSC SAME person SAME personShock Pause - Shock delivered Shockable Shockable Rhythm Sinus BradyRhythm: Sinus Bradycardia Start CC Start CC Start ET Start ET insertionStart etC02 Start etCO2 Start IO Start IO insertion Start IV Start IVinsertion Start IV Started IV Start Monitor Monitor Turned On Start O2O2 Applied Start Transport Start Transporting Stop Transport TransportStopped SuccX Succinylcholine SVT Rhythm: SVT Switch CC Switch CC TalkAirway Discussed Airway Options Talk Card-Vert Discussed use ofCardioversion Talk Epi Discussed use of IV Epi Talk etCO2 Discussed useof etCO2 Use Atropine Discussed Use of Atropine Using AED Using AED VFib Rhythm: V Fib Vasopressin Vasopressin Ventilate Pause - VentilationsVersed Versed VS Taken VS Taken Watches Team Team Leader: Assessperformance

The use of show-hide logic enables the system, equipment andmethodologies to be configured to operate in a once-done-it-disappearsmode of operation. For example, monitor arrival may be a one-time eventduring a Code; thus, once the Recorder selects the associated icon onthe task grid, it is no longer displayed (discussed below with regard toFIG. 36).

Likewise, there may be tasks that occurred before the code started andare not observed by the Recorder. These are termed pre-code tasks andare listed in Table 2. The developer can customize these for each code.They are triggered when the code is initiated and automatically recordtheir associated task(s), even though they do not appear on the GUI.These pre-code tasks may be used by the recordation and analyticssoftware incorporated in the disclosed embodiments to provide the GUI tocontrol what is displayed on the GUI for the Recorder to interact with.They are listed in Table 2.

Protocols define what responders should adhere to during theirmanagement of the cardiac arrest event. The developer can customize themduring the process of creating a code. They can then be included as abenchmark when analysis is performed. Protocols available are alsolisted in Table 2.

TABLE 2 Pre-Code Tasks Protocols AED used @ start Limit the # of EpiDoses allowed of recording CC Ongoing @ start Limit the # of VasopressinDoses of recording allowed Combitube in place @ start Metronome inDefibrillator of recording Crash Cart present before Start Using AHAtime for 1st Dose of Recording of Amiodarone etCO2 in place @ startUsing AED of recording Initial Airway done @ start Using Amiodarone ofrecording IO in place @ start Using CCR of recording IV in place @ startUsing CPR of recording LUCAS ON @ start Using Crash Cart of recordingManual defibrillator @ start Using Early Invasive Airway of recording ifInitally non-Shockable Metronome started @ start Using Epinephrine ofrecording Monitor ON @ start Using etCO2 of recording Using IO UsingLUCAS Using Manual Defibrillator Using Max Joules for Shocks UsingMetronome Using See-Through Rhythm Analysis Using Supraglottic AirwayUsing Vasopressin

These pre-code tasks may be used by the recordation and analyticssoftware incorporated in the disclosed embodiments to provide the GUI tocontrol what is displayed on the GUI for the Recorder to interact with.Additionally, these pre-code tasks may also define many aspects of thelogic used in analyzing the details and actions that occur during aCode.

However, it should also be understood that, in accordance with at leastone disclosed embodiment, the system, equipment and methodologies mayoptionally be configured to not use pre-code or protocol data. Thus, itshould be understood that the disclosed embodiments may be functional toperform, recordation, analysis, feedback, training, and post eventprocessing without reference to, or use of, pre-code or protocol data.

Analysis of details and actions during a Code may be availableimmediately. Analysis data and results may be displayed on the GUIand/or one or more monitors in communication with the. For example,analysis data and results may be projected for immediate review withpersonnel working on the corresponding cardiac arrest event.

Additionally, reports including a list of events recorded during thecode and the results of the performance analysis may be printed to oneor more local or remote printers for immediate or subsequent use, e.g.,for analysis of materials and medicine used on the patient during thecardiac arrest event. Generation and organization of reports isexplained herein.

A customizable set of benchmarks may be set up and used to analyze theevent details. This set of benchmarks may be set and stored when theCode is archived. They can be modified during analyses, if deemedappropriate, but cannot be changed after the code is archived. Thus,re-analysis, either immediately or subsequently at a later date, isenabled. Moreover, during re-analysis, the system enables the use andapplication of a different set of benchmarks to be used to analyze thecardiac arrest event data.

All data generated during cardiac arrest events may also be archived soas to be stored in a meaningful and accessible way for subsequent reviewat a later date. The information relevant to the type of Code (e.g.physician and registered nurse in charge, etc.) may be collected andstored and that information may be used to sort the archived data. Inthis way, the data is generated in real time during a cardiac arrestevent and is accessible and comparable with data from other events thatshare common characteristics.

The pre-code, protocol and benchmark used during a Code may be savedalong with the tasks performed during the Code. As a result, thepresentation of information using the equipment, system andmethodologies may be further improved on an ongoing basis to ensure thatthe Recorder can effectively utilize the GUI to record data andmemorialize details and actions that occur during Codes.

In accordance with at least one disclosed embodiment, patientidentifying information is NOT collected; therefore the data fromarchived Codes for that disclosed embodiment may also be made availablefor research purposes.

The archived data may be stored on the user equipment initially and/orstored on memory at a centralized location within a particulardepartment or facility to ensure that the data is maintained in anuncorrupted and secure manner and is accessible for re-analysis,compilation with other data and use by other computer systems providedwithin a facility, e.g., for inventory control in order to automaticallyorder depleted supplies, for billing purposes in order to accuratelycharge for used materials and medicine, for liability management inorder to track what batches of supplies such as medicine are used onwhat patients to track and minimize the risk of tainted supplies. Data(with patient-specific information removed) may also be archived in acentralized database that collects data from many users. In doing so aresearch database is created and becomes useful as long as theterminology used to define events recorded can be standardized.

Disclosed embodiments may be utilized in conjunction or be compatiblewith the McMAID concept. See Kellum M J. Improving performance ofemergency medical services personnel during resuscitation of cardiacarrest patients: the McMAID approach. Curr Opin Crit Care 2009;15(3):216-220, incorporated by reference in its entirety herein. TheMcMAID concept was originally developed to aid in defining sets of tasksthat can be delegated to and readily performed by single responders. Italso prioritized the order in which these tasks should be performed. Theacronym stands for the following: Metronome, Chest compressions (CC),Monitor (defibrillator), Airway, IV-IO, Drugs. In the display ofanalysis results, two additions to this sequence have been made forpauses and CC Summary. The nature of these results and how they may beanalyzed relative to benchmarking and real-time prompting during a codeis explained herein.

Presently disclosed embodiments can extend that usage to provideguidelines for the order in which tasks are to be performed during aCode. Thus, McMAID and similar protocols may be used to dictate theorder in which tasks and/or results may be presented to a Recorder onthe GUI. They may also be used to prompt the Recorder regarding whentasks should be performed. Here, again the use of show-hide logicenables the system and equipment to be configured to operate in aonce-done-it-disappears/new-icons-are-shown mode of operation, therebyminimizing the number of options available for data recording to reducepotential data entry errors.

Use of protocols such as McMAID may also provide benchmarking logic thatmay be used during objective analysis of the details and/or results oftasks performed during a Code. In this way, the disclosed embodimentsenable objective analysis of the details and results of tasks and eventsoccurring during a Code, which may be performed with reference to andcomparison with various benchmarks discussed herein. Accordingly, suchdata may be analyzed by looking at the occurrence(s) of each task anddetermining whether it was performed within an acceptable time frame andappropriately sequenced. Thus, benchmarks may define the limits ofacceptability.

As alluded to above, benchmarks utilized by the system may be modifiedby the Administrator; but unlike pre-code sets, which may be specific toeach code-type, a set of benchmarks may be used for all code-types.Multiple sets of benchmarks may be developed; however, one set ofbenchmarks may be designated as a default set prior to the system andequipment being using to process any Code.

Benchmarks may be grouped using McMAID logic, both during the design ofa benchmark set and during display of results of an analysis. One set ofavailable benchmarks is illustrated in Table 3. “Sec” refers to themaximum acceptable number of seconds between the two events in thebenchmark.

TABLE 3 Sec McMaid-Category Benchmark Name 15 Metronome Metronome - ToStart after Starting CC 150 Chest Compressions CC - Duration - Max 100Chest Compressions CC - Duration - Min 75 Chest Compressions CC - Timebetween Switching Compressors 20 Chest Compressions Start CC - afterPrior Rhythm Analysis - AED 8 Chest Compressions Start CC - after PriorRhythm Analysis - Manual 8 Chest Compressions Start CC - after PriorRhythm detected 3 Chest Compressions Start CC - after PriorShock/NoShock 20 Chest Compressions Start CC - after Start of Recording30 Monitor - Defibrillator Monitor - To Turn on after it's available 5Monitor - Defibrillator Pads - To apply - doing CCR 10 Monitor -Defibrillator Pads - To apply - doing CPR 10 Monitor - Defibrillator ToAnalyze Rhythm - AED 5 Monitor - Defibrillator To Analyze Rhythm -Manual defibrillator 15 Monitor - Defibrillator To Charge - using AED 0Monitor - Defibrillator To Charge - using CCR & Manual defibrillator 10Monitor - Defibrillator To Charge - using Manual defibrillator 5Monitor - Defibrillator To Shock - after Rhythm analysis 8 Monitor -Defibrillator To Shock - after Shockable Rhythm 120 Airway InitialAirway - after Start of Recording 120 Airway Initial Arway - after StartCC 360 Airway Invasive airway - Earliest time after Initial Rhythm -Shockable 390 Airway Invasive airway - Latest time after InitialRhythm - Shockable 30 Airway Invasive airway - Max time after InitialRhythm - Non-Shockable 30 Airway Max Time after Initially NonSockable toStart ET 15 Airway Start Mainstream etCO2 - after invasive airway ready60 Airway Start Sidestream etCO2 - after Start of Recording 0 Airway ToVentilate if doing CCR 5 Airway To Ventilate if doing CPR 20 IV - IO Maxtime to insert IO 20 IV - IO Max time to insert IV 3 Drugs Max # of Epidoses allowed 30 Drugs Max time 1st Amiodarone after Shockable Rhythm 15Drugs Max time 1st dose Epi after IV or IO ready 30 Drugs Max timebetween 1st Epi and 1st Vasopressin 660 Drugs Max time between 2nd and1st Vaspressin doses 300 Drugs Max time between Epi doses 540 Drugs Mintime between 2nd and 1st Vasopressin doses 120 Drugs Min time betweenEpi doses 0 Pauses Max pause - other reasons 10 Pauses Max pause toapply LUCAS 0 Pauses Max pause to do Pulse check - CCR 10 Pauses Maxpause to do Pulse check - CPR 0 Pauses Max pause to insert ET - CCR 10Pauses Max pause to insert ET - CPR 0 Pauses Max Sec Allowed forPeek@Rhythm Pause 60 Pauses Max time Crash Cart arrval - after Start ofRecording

In accordance with at least one embodiment, the system may provideflashing functionality, wherein an Administrator can define what eventsthey want the Recorder to be reminded of during the various phrases of aCode. The logic may be linked to benchmarks explained below. Flashing,which may be optionally disabled by the recorder, involves rememberingwhen a trigger event occurs and then warning the recorder (by blinkingthe target event) a specified interval before the target event is dueaccording to its associated benchmark interval. When that interval hasbeen reached, the target event is colored red and blinks

As shown in FIG. 4, prior to use of the system by a Recorder, anAdministrator must set up the Codes that will be used by the system. Tothis end, an Administrator may be presented with a screen that providesinstructions for creating a new Code to be used by the system andequipment. As explained on the introduction screen for creating newCodes in FIG. 4, the system and equipment may record, analyze andgenerate reports regarding the tasks and events that occur during aCode. However, prior to recordation, the Administrator must exactlydetermine what needs to be recorded, when it should be recorded and howthe results of that recordation should be analyzed. This processinvolves a number of operations and may include actual creation of aCode that may be used in the system, i.e., creation, or practicingcreation of a Code (e.g., to enable the user to train on how to use thesystem and set up a system configuration that is effective).

Customization may be enabled using a hierarchy of format—division—site,which may allow allows Administrators to develop system-wide Codes andthen modify them accordingly to meet local (division/site) needs. Forexample, all system-wide Codes for the format may be displayed. When aspecific code is selected, the dates when it was started and lastrevised may be displayed—as shown in FIG. 4A. Likewise, new divisionscan be added but duplicate names may not be allowed as shown in FIGS.4B-4C. Additionally, existing divisions can be renamed or deleted asshown in FIG. 4D.

Selecting an existing Code then allows the Administrator to continuedeveloping the Code or to copy it. If a Code has been run in the past,and therefore has archived data linked to it, its content cannot bemodified—instead it can be copied and the original Code may beinactivated so that it no longer will show on the screen (as illustratedin FIG. 4E on the left). If the Code has not been completed, developmentcan be continued. Finally, as shown in FIG. 4F, a Code for a new sitecan be developed, the site itself can be renamed, or the site can bedeleted (but only if no Code has been attached to it).

FIG. 5 illustrates another example of the Code Development screen(s)provided in accordance with the disclosed embodiments. By enabling theAdministrator to develop a Code, the system and equipment enable usersto customize the presentation of tasks and events for recordation by theRecorder. In doing so, the Administrator is able to ensure that thescreen contents are user friendly for the Recorder. However, it shouldbe understood that the need for customization must be weighed with theneed for standardization so as to enable generated data to be usefuloutside the context of the disclosed system, equipment, Location andRecorder. For example, the generated data may be input into other dataprocessing systems; as a result the data may need to be in a prescribedformat for those systems' use. In other words, local definitions thatare generated and understood by local users are valuable; however, ifthe Code data is to be archived and made available to other systems thenstandards would need to be available that enable meaningful comparisons,sorting and characterizations.

The Utstein criteria have been utilized for years by the resuscitationcommunity in this regard. The Utstein criteria is a set of guidelinesfor uniform reporting of cardiac arrest. The Utstein criteria, or Style,was first proposed for emergency medical services in 1991. The namederives from a 1990 conference of the European Society of Cardiology,the European Academy of Anesthesiology, the European Society forIntensive Care Medicine, and related national societies, held at theUtstein Abbey in norway.

In accordance with at least one disclosed embodiment, a centraldictionary may be maintained and be available to Administrators who thenmay add to or download events they want to include in theirimplementation. This maintains standards by assigning mother-identifiersto all events used by all users, which may then be included in archiveddata. Administrators can then rename events to fit their local dialect,as long as the nature of the event is unchanged. Similar logic may beutilized to transmit whole Codes that may be needed if a mother systemdevelops and disseminates training Codes that are designed to meetstandards of recognized expert agencies, e.g., the American HeartAssociation's Advanced Cardiac Life Support (AHA ACLS) that isperiodically revised.

When the disclosed embodiments are used for training and evaluation,some training scenarios may contain additional events and tasks thatneed to be discussed or recognized by a trainee and performanceevaluated. This process may occur before and/or after the actualresuscitation portion of a training code.

In order to simplify management of events (also referred to as words),the events may be divided into logical categories. For example, Codeevents may be those events that occur during the resuscitation effort.Others words that are utilized in the before and/or after the Codescreens may include topics discussed, recognized things and actionstaken. Thus, a screen may be organized around these categories, e.g., asillustrated in FIGS. 6 and 7, wherein a word category is selected andthe terms associated with that category are displayed.

Moreover, as shown in FIG. 8, when a word is selected, itscharacteristics can be modified including, the name displayed on thegrid, for example, how it fits into the task grid's icon, thedescription that appears in reports, a phrase used to describe the wordto voice recognition logic utilized in the system, the McMAID category,(where a drop-down list displayed), and/or whether it is a billableevents associated with it. Additionally, using this screen, the user maybe presented with two options: add a new pair (icon name and descriptionand associated properties) and/or delete an existing pair. When adding,duplicates may not be allowed and deletions may only be allowed if anevent/word has not been utilized in an archived Code, e.g., see FIG. 9.

In accordance with at least one disclosed embodiment, a synonym databasemay be provided that enables linking of voice recognition technology totask recordation. Thus, a specific check on the uniqueness of voicerecognition phrases may be performed. There may be, for example, twocategories of synonyms: those for a single word and those for a phrase.

Thus, words that exist in the vocabulary discussed above may beorganized as above: by type and based on where, in the Codes' screen(s),the word appears (before, during, or after the Code). For example, asshown in FIG. 10, the word “completed” is used as a synonym for “done”.The prompts concerning the term's use may not be shown; however, theprompts enable a user to change their mind and avoid duplicate entries.Once a word has been accepted, the word may appear in other phraseswhere the word “done” is used. The logic to implement this feature issimilar when entering a relationship, e.g., type of synonym=phrase.Thus, the entered sequence of words may be linked to an event describedin its voice recognition phrase.

This approach to synonyms enables increased utility when using Nuance's®voice recognition technology and interfacing with Microsoft® Access(and, in theory other Microsoft® based products). This is becauseNuance® can only place its voice recognized words in a single window.Therefore, since multiple windows (screens) may be used in a code, awindow may be dedicated to voice recognition. Words deposited in thisdedicated window may then be processed to define a single specific eventfor recordation. In this way, it appears as it would be if it wasselected in a current screen. It should be understood that this ismerely one exemplary implementation and may be accompanied by a voicerecording component that can be referenced to resolve incompleterecognitions.

As mentioned above, pre-code events are particularly useful for cannedtraining scenarios. However, in some disclosed embodiments, the abilityof an Administrator to use pre-code events may impede accurate recordingof real-life cardiac arrest events by improperly generalizing a setupexisting before a Code begins. Accordingly, in accordance with at leastone embodiment, selecting a recorded event by holding down anAlt/Ctrl/Shift key while clicking it may be used to indicate it happenedbefore recording was begun. This approach may be utilized when recordingthe resuscitation of a real victim. Thus, turning to a more detaileddiscussion of how an Administrator may develop a Code, FIG. 11,discloses a Code Development screen of the GUI designed in accordancewith the disclosed embodiments. As shown in FIG. 11, an Administrator orDeveloper is shown a list of required components and may proceed to ascreen by double-clicking an item in the list. As can be seen in theexample of FIG. 11, the Administrator has already completed add/editswords used, and protocols; however, the Administrator still needs toaddress benchmarks for analysis, flashing reminders in the Code, eventsoccurring before the Code starts and drugs used. Whenever changes in onescreen require revisiting another screen, the status indicator box iscolored yellow and completion-status is revised to incomplete until theaffected screen is revisited. Explanation is now provided of onexemplary, non-limiting configuration for the GUI and the associatedsoftware running on one or more servers.

In accordance with disclosed embodiments, the system and equipmentprovide one or more screens in the GUI associated with and supportingthe disclosed functionality. Examples of the structural configurationand logical components and relationship of the screens are illustratedin the figures. For example, as shown in FIG. 12, illustrates thestructural configuration and logical components and relationship of atleast one Main Menu screen that may be utilized by two types of users,whose access to the functionality of the system and equipment differbased on the their roles. The first type of user is the Administratorhaving full access to all system functionality. The second type of useris a Reorder that can only record a code.

All users enter the program via the Main Menu screen (portions of whichbeing illustrated in FIG. 13A). Only active users with a valid passwordmay be allowed to use the system, equipment and methodologies provided.Both the user name and password may be checked. If either or both areinvalid, a message is displayed. In the example illustrated in FIG. 13B,both failed.

As mentioned above, Recorders are only allowed to enter data on a Code.When the user is determined to be a Recorder after signing in on theMain Menu, that person is taken directly to a Start Code screen (asshown in FIG. 14) that then initiates the set of Code Recordationscreen(s) (shown in FIG. 17). Likewise, Administrators can also view theStart Code screen but can also access other functions (listed in FIG.15). These consist of viewing archived codes, creating synonyms forvoice recognition, management of passwords, viewing and printing variousreports, changing the marker displayed on performance analysis screensdenoting a possible entry error, and creating new or editing existingcodes.

A third type of user, the Developer, has access to the same functions asdiscussed above for the Administrator and shown in FIG. 15. However,optionally, only the Developer can access the last two on the listillustrated in FIG. 15. These functions involve standardization ofterminology and should be delegated to a minimal number of individualswho take responsibility for these actions.

The system logic used in starting a code is shown in FIG. 16. The Useris asked to select a code from the list as shown in FIG. 17. Only codesthat have been completely developed are shown in this list.

Turning to an explanation of how Codes are actually recorded using thedisclosed embodiments, FIG. 18 illustrates configurations andrelationships of various screens displayed on the GUI that are used torecord tasks performed during a Code, and which may be augmented byvoice recognition technology if available. Performance of tasks may betimed using a system specific clock (incremented in minute: secondformat), and except for real Codes, where recording is continuous, thesystem clock can be temporarily paused and restarted.

Tasks may be displayed for selection on a grid. The current state of theCode changes after each task is performed; and grid content is updatedafter each task is recorded to reflect this state. A task list may beused to display all events recorded and its contents may be editable.During pauses and after recording is completed, an objective analysismay be immediately available, and may be used to discuss responders'performance.

Since only codes that have gone through all the code-creation steps areavailable on the Start-code screen, as explained above, the pre-code set(or other data) may define both a protocol used during the Code and aseries of tasks that occur before the start of the Code. The protocol(or other data) may be used to determine which drugs are availableduring the Code and which devices are available. The pre-code tasks (orother data) may be included in a task list to be displayed using the GUIof the disclosed embodiments. The add/rename words process revises taskand task-display names for a subset of task names. Likewise, thepre-code tasks also modify the initial state of a grid display providedto the Recorder during Code documentation recording.

For example, all drugs (medications) that are available for use may bedisplayed on a screen with the GUI, either on the screen's grid or in anauxiliary list displayed in a pop-up form. Drug words may have anadditional property, e.g., dose. Thus, when a drug is administeredduring a Code, the Recorder is asked to enter the dose; and, if none isentered at that time, its usual dose is presumed to be given with theunderstanding that this may be revised before the Code data isconsidered accurate and the Code is archived.

Upon entering the set of screens presented to a Recorder during Codedocumentation recording, the task grid may not be visible on the screenif the system clock has not been started, and the status of compressions(which may be visible on subsequent screen shots) may not be visible.This situation only occurs in training codes where starting a code maybe delayed until the trainee is ready. In real codes, the clock isstarted when the screen is shown (and as mentioned above cannot bepaused until the code is completed).

All code-types, except real codes, may utilize the Start icon asillustrated in FIG. 19. Selecting (e.g., a user selecting the Starticon), may trigger display of the task grid and starting of the systemclock along with displaying the status of Chest Compressions (CC) on ascreen of the GUI. As illustrated in FIG. 20, because the Start CC taskhas not yet been selected, the CC status may be paused. The organizationof tasks on the task grid may be predetermined by a Developer using theOrganize Tasks on the Grid screen illustrated in FIG. 2 explained above.The initial contents of the task grid may also be selected by theAdministrator.

The visibility of the pause and analysis icons may also be code-typedependent. For example, the Mock and Testing Code scenarios areeducational in nature and pausing to analyze and discuss what hastranspired is appropriate functionality. Alternatively, recording in areal Code may be continuous. Therefore, in real codes, pausing andanalyzing may not be allowed (e.g., these icons may not be visible onthe screen displayed on the GUI); thus, optionally, only the exit anddone icon options may be available, as shown in FIG. 21.

When the done icon is selected as shown in FIG. 22, the warningillustrated in FIG. 23 may be displayed (and the clock is paused—evenduring real codes—so as to not introduce inexplicable pauses). If theuser answers no or cancel, they can then resume entering data as beforeby selecting the start icon. If the message above is answered yes,recording may cease and cannot be resumed. The Code Analysis screen maythen be displayed, an example of which being illustrated in FIGS. 41-55discussed below. Thus, after the analysis is reviewed and presumablydiscussed and any corrections to the events recorded are completed,selection of the back to code icon on the Code Analysis screen maytrigger display of the screen(s) for enabling resumption of recording ofa Code; however, if the Code Analysis screen is reached after the codeis done, editing can be performed for the Code but no further tasks canbe entered.

Selection of the exit icon on the Code recording screen can beproblematic because all data entries may be deleted as a result.Accordingly, the message illustrated in FIG. 24 may be illustrated. Ifyes is selected, all data may be discarded and the user returns to theStart-a-Code screen.

In accordance with the disclosed embodiments, run report codes mayrequire specific functionality because data may be enteredretrospectively. For example, data may be entered from a report of somekind after an event; however, sometimes tasks may be entered while aRecorder is observing or listening to a computer download that runscontinuously (albeit with a different time reference the equipment andsystem of the disclosed embodiments). These two recordation methods maybe termed “manual” (e.g., data and timing is observed or listened to andinput by the Recorder) and marking (e.g., the timing is recorded by theprogram running on the GUI but the user can enter the specific eventassociated with that “mark” at a later time). It is useful for thesystem to be configured to optionally accept designation of the inputmode for such data as shown in FIG. 25. The entry mode can be changed atany time.

In manual mode when recording a Run Report, the system clock may not beused. Instead, the occurrence time for a task may be entered by theRecorder when that task is selected. For example, the exampleillustrated in FIG. 26 shows a screen section that is only visible forRun Report codes. The start recording time may be entered earlier whenthe Recorder elects to start a Code. Thus, the current time may beinitially set to the start recording time. Entries in the append field(used to correct the recorded time) illustrated in FIG. 26 may beappended to the current time value; and since appending involves onlythe terminal portion of the current time, this process eliminates theneed to re-enter all the digits required for a time. Non-numericcharacters may be ignored in this process. The entry field's color maychange. The revised current time may be displayed in the clock field onthe screen and be used to time stamp the next grid task entry. In theexample illustrated in FIG. 27, the value 55 is appended to the time23:10:45 resulting in a time of 23:10:55. Thus, the new revised currenttime is then displayed in the clock section, as shown in FIG. 28, andused as the time of the next task entered.

The marking mode allows the Recorder to play back a timed stampeddownload recording of events that transpired during a Code. If theclocks of the displayed screen and download are synchronized when thedownload is played, the grid can be used to record tasks in a continuousfashion. This may be accomplished by entering the starting clock timefor the download into the system clock as shown in FIG. 28. Thus, when adownload and a displayed screen are stated at the same time, events canthen be recorded in two ways: selecting a specific task on the grid whenit occurs; or selecting the mark icon (instead of a specific task). Whenthe mark icon is selected, a special task is entered in the list ofevents, as shown in FIG. 29.

As mentioned above, accurate recordation and documentation of the timingof tasks during a Code enables objective analysis, feedback anddocumentation of the tasks performed during treatment of a cardiacarrest event. As discussed above, in some code-types, the system may bepaused, e.g., during Mock and Testing code-types. During a pause, if theRecorder selects the marked entry and then selects a task such as startCC, the system and equipment may log that task using the marked entrytime, as illustrated in FIG. 30. Likewise, selecting the start icon maytrigger restarting of the clock and the start icon is hidden and thepause icon becomes visible.

However, in real Codes, where pausing and analyzing is not permitted, noanalyze icon may be included in a displayed screen set associated withrecording a Code. Rather, only the done icon may be illustrated, andwhen it is clicked and confirmed, the Analyze button appears.

Within the task grid displayed within the Code Recordation screen(s),when a task is selected, the system and equipment may respond byperforming a serious of operations. For example, the displayed task gridmay be altered to reflect the dynamic state of the Code by, for example,using the show/hide logic associated with each task. Using such logicreduces the number of choices the Recorder has to choose from, which intheory should reduce data entry errors. Additionally, tasks that areonly performed once may not be erroneously re-entered. For example, asillustrated in FIG. 31, if the metronome icon was selected by theRecorder, the icon may disappear from the task grid.

Likewise, the use of show-hide logic enables the system and equipment tobe configured to operate in a once-done-it-is-replaced mode ofoperation. For example, monitor arrival is a one-time event; thus, oncethe Recorder selects the associated icon on the Task grid as shown inFIG. 32, the icon disappears. However, the newly arrived monitor woulduseless until it is turned on; thus the Task grid may also include amonitor on task icon, as shown in FIG. 32. It should be appreciated thatthe interval between when the monitor arrived and when it was turned onmay be analyzed, as a result. This same logic may be applied tosituations where the icon content toggles; e.g. if something that startsmay fail and then needs to be re-started, the icon content togglesbetween xx-Start and xx-Failed. During the development of a code thisprocess is termed “cycling” and a screen is available to create sets ofcycled events.

Similarly, the start CC task may occur only once. Thus, when it isselected by the Recorder, it may be replaced by two other CC options:switch and [resume by] same person, as shown in FIG. 33.

Further, some tasks may follow a logical sequence in their performance;that is they can only be performed after a prior event occurs.Accordingly, systems and equipment provided in accordance with thedisclosed embodiments may utilize program logic that prevents such tasksfrom being logged before a prior necessary precursor event occurs. Forexample, the cardiac rhythm must be analyzed before the type of rhythmcan be determined. Thus, the analyze rhythm icon must be selected priorto display of two alternative rhythm choice icons, shockable andnon-shockable, are displayed on the screen. Similarly, the type ofrhythm must be determined before a decision on how to manage the rhythmcan be made. Thus, the type of rhythm, shockable or non-shockable, mustbe selected before a shock or no shock selection is input by theRecorder. Further, selection of either a shock or no shock icon maytrigger display of content as illustrated in FIG. 34. In accordance withat least one embodiment, the choices (e.g., shock or no shock) availablemay be colored to prompt the Recorder in making the appropriateselection.

In accordance with disclosed embodiments, a task may be time stampedwhen it is selected by a Recorder on the Code Recordation screen(s)associated with a code-type and output on the GUI. Optionally, all tasksthat have been entered into the screen sets may be displayed in a tasklist located to the right of the task grid of a screen. Thus, asillustrated in FIG. 35, the tasks with times of 0.00 were performedbefore the Code was started—when the pre-code logic associated with thisCode was activated. Note, in accordance with various embodiments, thetask names in the list may be more descriptive than on the task gridicons. Moreover, the tasks in the list can be edited; for example,selecting a list entry may allow the user to delete the task in FIG. 36.

Right-clicking an entry on the list may enable correction of anerroneous task entry. Note, this may not be permitted during a Real Codeuntil recording has ceased (e.g. by selecting the done icon); however,for other code-types this correction may be permitted during a pause inrecording. In at least one implementation, the task itself, but not thetime stamp may be changed, as illustrated in FIG. 37.

As explained above, in accordance with the disclosed embodiments, realCodes cannot be paused, whereas, for other code-types, the entry oftasks can be paused. Pausing is usually done to discuss some aspect ofresponder's performance; and such a discussion is aided by the abilityto analyze events that have occurred up until the pause. Pausing alsopermits corrections of previously entered tasks, as mentioned above. Thesystem clock stops during the pause; and it is resumed when the starticon is subsequently selected. Task entry may then be resumed.

Turning to the ability to analyze archived Codes provided in accordancewith the disclosed embodiments, FIG. 38 illustrates the architecturalconfiguration of screens presented to a user to enable analysis ofarchived Codes. In operation, after a list of all archived Codes hasbeen displayed to a user (e.g., sorted with the latest on top), only twooptions may be available: exiting to the Main Menu screen(s) orselecting one of the archived Codes to analyze, as shown in FIG. 39. Auser may select one of the displayed Codes and, when an old Code isselected, it is analyzed using an original or selected benchmark set, asexplained below. Subsequently, a Code analysis screen or set of screensis output to the user via the GUI. Actions available on that or thosescreens pertain to analysis of actions and data documented asillustrated in FIG. 40.

The benchmark set assigned to and employed when a Code is started may beused to initially perform analysis of the Code. The Code data analyzedmay come from one of two sources: an archived Code, as explained inconjunction with FIG. 39, or a Code just previously entered, forexample, when the system and equipment are being used for training orwhen a real code is concluded.

When displaying analysis of a Code, the screen or set of screens forCode Analysis may include a list of tasks performed, e.g., for thepurpose of modifying its content or discussing tasks and/or events thatled to a specific analytic result. However, because the Code analysisitself is the primary purpose of the screen, this list may be only anoption or not displayed initially on the screen(s).

McMAID logic may be used to organize presentation of the analysis on thescreen(s). Arrow keys may be used to select a category of data for theCode, for example, data pertaining to the Metronome, Chest compressions,Monitor, Airway, IV/IO, Drugs, Pauses and/or a CC summary, asillustrated in FIG. 41.

Once a category is selected, the results for the category may bedisplayed on the screen(s). Results may also be grouped into failed andpassed categories (examples are illustrated in FIG. 42-43 pertaining tothe use of a Metronome to guide chest compressions, FIG. 43 pertainingto Chest Compressions (CC), FIG. 44 pertaining to the use of themonitor, FIG. 45 pertaining to Airway related tasks, FIG. 46 pertainingto the insertion of an IntraVenous (IV) or IntraOsseous (IO), FIG. 47pertaining to the administration of drugs, FIG. 48 pertaining to theinsertion of pauses (if permitted based on code-type), and FIG. 49 whichprovides a summary of Time spent Doing Compressions and the Impact ofPauses upon Compressions).

As mentioned above, the benchmark set used to analyze the Code data canbe changed by selecting a change benchmarks icon provided on the analyzeCode screen or set of screens as shown in FIG. 50. As a result of such aselection, control may then be shifted to one or more screens in the GUIassociated with benchmarking that display the contents of availableexisting benchmark sets for selection, as discussed herein.Administrators can also develop a new set and use this for are-analysis. The benchmark set utilized in the analysis, whether it bean originally selected benchmark or a new one selected using a changebenchmarks icon provided on the screen(s), may be displayed on the CodeAnalysis screen(s) as illustrated in FIG. 51. Likewise, a list of taskscan be displayed by selecting a show code details icon provided on thescreen(s), an example of which being shown in FIG. 52. In accordancewith at least one embodiment, changing the benchmark second for anindividual benchmark is possible.

For example, as shown in FIG. 53, various details taken from an ArchivedCode (where Start Time is known) may be presented with the time beingdisplayed using 24 hour clock format.

Alternatively, as illustrated in FIG. 54, if a Code was just recorded,the time may be displayed using a Minute-Second format (representing theinterval since recording began) so that input errors detected in thelisted details may be more readily identified if the user returns to theCode Recordation screen to edit such entries. Because the start time ofthe Code just entered may be, at the time of data display, not known,that time may be entered in an Archive Code screen when the done iconfor the Code is selected. It should be understood that entries in thedisplayed list cannot be edited if the code is an archived code.However, the list entries could be edited if the code is being recordedis possible by selecting the back to code icon, as shown in FIG. 55.

Exits from the code analysis screen(s) depend upon the type of codebeing analyzed. Thus, when analyzing an archived code, both the back tocode and done with code icons may be available to exit the Code Analysisscreen(s). Likewise, when analyzing a just recorded Code, the back tocode icon may be available to exit the Code analysis screen(s). Further,when analyzing a just recorded Code, the done with code icon may beavailable to exit the Code Analysis screen(s).

In accordance with disclosed embodiments, the system and equipmentprovide one or more screens associated with a Recorder archiving a Codeusing the GUI. An example of the structural configuration andrelationship of the Code Archival screens being illustrated in FIG. 56.

Once the Code Archival screen(s) are displayed on the GUI, recording ofCode events has been completed, performance has been analyzed, feedbackhas been provided, and responders are ready to move on to the next taskat hand. Thus, at such a point in time, the system and equipment of thedisclosed embodiments has served a primary purpose of providing timelyfeedback and education regarding a Code. However, the system andequipment have additional utility in that the Code may be documented forsubsequent use and for generation of data that may be input into othersystems at a medical facility, e.g., records, billing and inventorysystems. Thus, although archiving a Code may be considered ahousekeeping activity, archiving is essential for individual orcollective retrospective reviews of performance and cross departmentefficiency improvement. Thus, the data collected on this set of screensshould be viewed from that perspective. Report generation is aretrospective activity with ongoing value.

During the archival process, information regarding which benchmarks,pre-codes and protocols that may have been utilized is maintained andsaved along with the time stamped events recorded during the Code.Additional information that may be relevant to performance improvementefforts is also obtained. (see FIG. 57) For example, the arrest type,arrest date and recorder fields on the Code archival screen may bepopulated using prior entries. The arrest date and arrest time may referto when the victim's cardiac arrest began, e.g., when collapse occurred.This information may be known for Mock and Testing Codes; it may alsohave been previously recorded by the Recorder when the recorder wasusing the Code recordation screen(s), e.g., the Start a Code screen.Therefore, the arrest time may be only entered for real Codes. Thearrest time may be entered in either 24 hour clock format: 21:14:22 oron a 12 hour AM/PM format 9:14:22 PM. In accordance with at least oneembodiment, data consistent with the UtStein criteria can be entered andattached to the archived code (by the Administrator who is prompted todo so) retrospectively.

When reports are generated, the arrest time may be used to convertrecorded clock times to actual 24 hour times. A comments section (asillustrated in FIG. 57) may be expand in size if necessary. Uses wouldinclude why protocol deviations occurred, why certain benchmarks used inanalysis were unrealistic, justifying for other whys. The validity ofentries may be checked before saving and, if data is missing, an errormessage may be displayed (an example of which being illustrated in FIG.58). During the archiving process, events recorded are translated into astandardized vocabulary that is understood by all systems, enablingretrospective analysis by researchers of a large number of codes.

Data may be initially saved on the computing device used to record theCode. Subsequently, it can be sent to other appropriate systems, dataanalysis systems and/or storage devices. After the Code has beenarchived, the user may be returned to the Main Menu screen(s). No otherexit icon may be provided ensuring that all data is saved once it hasbeen acquired.

Pre-codes define events that occur before the start of the Code andtherefore are not observed by the Recorder. They are enteredautomatically at the start of the Code, are logged as occurring at timezero, and impact the GUI context-sensitive content. Their use is usuallylimited to training codes. The development process, as shown in FIG. 59,is quite simple: double-click a pre-code entry to toggle its statusbetween selected and not selected.

In accordance with disclosed embodiments, the system and equipmentprovide one or more screens associated with definition of benchmarkingdata using the GUI.

Adding a new benchmark is not possible; rather, users may only editexisting benchmarks. Benchmark sets are in some ways similar to pre-codesets explained above in that they may be developed by Administrators,have default sets that may be automatically selected when a user startsa Code, and may influence the analysis of a Code.

However, benchmark sets differ from pre-code sets in that they are notcode-type dependent, do not affect the logic used to displays tasks onthe grid, do not cause tasks to be added during the Code, do not impactlogic guiding the analysis of a Code (they only affect the judgmentlogic, e.g., pass or fail logic) and do not influence the recording of aCode. Each benchmark has 3 components: a triggering task, a target task(the one that should be subsequently performed and a time interval (inseconds) between them that represents the maximal accepted interval.Default intervals exist for each benchmark. During the creation ofbenchmarks for a given code, the benchmarks are grouped on the screenusing the McMaid category they belong to. (FIG. 60).

In accordance with at least one disclosed embodiment, the benchmark setselected in the Code Recordation screen(s) may be changed whenperforming an analysis. What happens after such a change is user typedependent. For example, when the user is a Recorder, the Recorder mayuse an alternative set during analysis discussions; however, Recordersmay not be allowed to modify which benchmark set is used in a finalanalysis because an Administrator made that decision when the defaultbenchmark set in the Code Recordation screen(s). Recorders can only viewthe contents of a benchmark set; they cannot modify set contents ordevelop a new set. Administrators can do what is not permitted for aRecorder.

In accordance with at least one embodiment, benchmarks for all sets maybe grouped using the McMAID categories shown on the left in FIG. 60.Thus, in this example, when a category is selected (e.g., using arrowkeys may be easier than selecting an icon), the associated benchmarksmay be displayed. In the example illustrated in FIG. 61, only onebenchmark exists for metronome and the name and the default benchmarkSec (second) are displayed.

Within the benchmark screen(s), if an item is selected, the originaldefault or user modified value in seconds for the benchmark seconds maybe displayed as illustrated in FIGS. 62A-B. If the benchmark secondsvalue is edited it becomes the new second value (sec) for that benchmarkitem. Examples of the benchmarks for other McMAID categories of abenchmark default set are shown in FIG. 63A-F.

In accordance with disclosed embodiments, the system and equipmentprovide one or more screens associated with Program Development usingthe GUI. An example of the structural configuration and relationship ofthe program development for password input is illustrated in FIG. 64.The Program Development screen(s) may be used only during development ofsystem functionality and may not be accessible to Recorders. Thus, aDeveloper, with a prescribed password, may access these screens from theMain Menu screen(s). Optionally, the Program Development screen(s) maybe accessed by an Administrator, e.g., if a justification for theAdministrator's request to make changes in the task grid is deemedvalid.

One of the Program Development screens enables the ability to organizetasks on the task grid, as illustrated in FIG. 65. Thus, the taskselection tool, i.e., the grid, is shown on this screen and consists ofrows of task icons (as illustrated in FIG. 2). Each row contains acategory name and contains tasks in that category. All available tasksare either on the grid or in an adjacent list of unassigned tasks (FIG.66) Task icons (in FIG. 2) 210 with tasks assigned to them differ fromicons 215 that have no task assigned to them. Tasks cannot be assignedto icons in the Status row because this row is used to display thecurrent status of one of the interventions selected in the row above.

Selecting on a task in the unassigned list and clicking on a grid iconremoves it from the list and places it onto the grid. In FIG. 67 StartCC is selected in the list and when a grid icon is clicked (FIG. 68) itis placed on the grid and removed from the unassigned list. Although notshown in the figures, if a grid icon is occupied by a task and that iconis selected for a task in the unassigned list, the initial task on thegrid is removed and is placed in the unassigned list. The reverse isalso possible, i.e. clicking an icon with an assigned task removes thetask from the grid and places it in the unassigned list.

In accordance with at least one disclosed embodiment, drugs may beplaced either on the grid (in row(s) dedicated to drugs) or on aseparate list that will be used to populate a popup screen (that isaccessible by an “other drugs” icon on the grid). This option minimizesgrid data displayed by including only commonly used drugs on the gridand yet allows the selection of less commonly used drugs when needed.

In accordance with at least one disclosed embodiment, functionality maybe provided to enable reversal of a change, e.g., by a user inputting anAlt-Z key stroke, and multiple reversals may be possible.

In accordance with at least one disclosed embodiment, there may be nosave icon on the Program Development screen(s) because each change maybe saved in the system and equipment files when it is made.

Optionally, although not shown in FIG. 2, the Program Developmentscreen(s) may also include a print icon that triggers output of aprintable report showing task locations on the grid displayed, as shownin FIG. 69.

As mentioned above, the relative ease of use provided by the systems andequipment designed in accordance with the disclosed embodiments at leastpartially results from the use of show-hide logic that enables theability to show or hide tasks on the grid using logic associated withthe preceding task entered. Thus, in accordance with disclosedembodiments, the system and equipment provide one or more screens in theGUI associated with setting up the relationships between tasks and datato determine what is shown in association with each individual task. Anexample of the structural configuration and logical relationship of theshow-hide selection logic is illustrated in FIG. 70. The Show-HideSelection Logic screen(s) may be used by an Administrator or Developerto determine which tasks are initially shown on a task grid or designatewhich child tasks to show and which child tasks to hide when a specificmother grid task is selected. Thus, as explained with relationship toFIG. 71, a show/hide selection process may be initiated by selecting anaction icon (as shown in FIG. 72). After an action is selected, a usermay be prompted to select any task on the grid to designate that task asthe mother task. As a result, the Mother task's name may be displayed inthe action box and child tasks for that mother may be highlighted, e.g.,by a specified colors. As shown in FIG. 73, tasks to be shown when themother task is selected are colored green and those hidden colored pink.Unaffected tasks retain the blue color. Subsequently the designation ofthe child tasks can be modified by selecting either shows or hidesbuttons shown in FIG. 72. Likewise, the modifications may be reversible.

By utilizing the Show-Hide Selection Logic screen(s) the user candetermine which subset of tasks will be shown when the grid is initiallydisplayed. Selecting the initial shows icon may change the color to adifferent color. This initialization process is distinct from theshowing of tasks discussed in Organize Grid Tasks screen(s) discussedabove (see FIG. 2) in that the latter controls the visibility of tasksselected after a task grid has been initialized.

A secondary use of benchmarking is to detect input errors; using thetiming of performance of tasks that are sequentially related. Manyerrors can be prevented by using the show-hide logic presented above tominimize the number of tasks available for selection. However, keeping atask hidden until another is performed can also confuse the user, e.g.,not being able to record a task when it is performed because theantecedent task was erroneously not entered. This is a prioritizationissue that is discussed below where applicable. Examples of benchmarkingresults are shown in the description of the Code Analysis screen(s)explained above (see FIGS. 45-53).

In the Code Analysis, screen, benchmark subsets may be defined andpresented using the McMAID concept. These categories are explainedfurther below; and they may be used to group the benchmarking processesinto the following: Metronome, Chest Compressions (CC), Monitor(defibrillator), Airway, IV-IO, Drugs, and Pauses. Within each McMAIDsubgroup, pass/fail grades may be assigned to each benchmark item andpauses in compressions may be analyzed. Finally, an analysis of the timespent doing compressions, doing acceptable pauses, and doing unnecessarypauses may be performed.

Within the Metronome benchmarking category (FIG. 42), metronome usagemay be tested for all code-types, e.g., was it used, if it was used, wasit started on time.

Within the Monitor (Defibrillator) benchmarking category (FIG. 44),crash cart arrival may be tested for real and mock codes. For example, acrash cart should arrive within a benchmarked interval after the startof recording a Code; however, this may not be analyzed if the pre-codeset has the crash cart present at the start of recording. Within themonitor usage benchmarking category, for most Real and Mock Codes themonitor is physically located on the crash cart; however, in somesituations (e.g., AED may be available, thus, a defibrillator/monitormay be used independently of crash cart arrival). Therefore, monitorusage may be treated independently of crash cart arrival; in fact it maybe considered essential for any Code (e.g., without a monitor rhythmanalysis and delivery of shocks is not possible. The program logic mayprevent turning on the monitor until it is available. Although theanalyze rhythm icon could have been hidden until it was selected (e.g.,using show-hide logic), this may not be done because benchmarking therhythms is more crucial than monitor usage.

Turning the monitor on as early as possible is encouraged becausemonitors record information vital to subsequent analysis of events:voice recording of events, continuous EKG recording, chest compressionquality and etCO2 recordings. At least one disclosed embodiment may notincorporate this data into an immediate analysis process; however, atleast one disclosed embodiment may incorporate this data.

Within the Monitor (Defibrillator) Pads benchmarking category (FIG. 44),it may be assumed that defibrillation paddles, common in older lesseffective monophasic defibrillators, are not used; insteaddefibrillation pads may be employed for this purpose. Therefore, paddlesmay not be included as a pre-code option; however, this could be done(as a customized version) if needed. Since the shockable/non-shockablenature of the Code is unknown until a rhythm analysis is performed,delaying pad application until after an analysis (using monitor leads)may be considered suboptimal care. Pad application therefore should beperformed before a first rhythm analysis is anticipated. If doing CCR(which advocates an initial period of continuous chest compressionsbefore the first rhythm analysis), it may not be, for example, doneapproximately two minutes after starting CC.

If doing CPR, there may be, within the monitor (Defibrillator)benchmarking category, no standard available. However, pads should beapplied as soon as possible after a monitor is turned on becausedelaying sacrifices early EKG recording, However, such a delay may benecessary if staff is limited and other activities are more urgent.

Likewise, although rhythm analysis is possible using monitor leads,doing so may be suboptimal care because the purpose of analyzing is todeliver a shock if needed, shocks cannot be delivered using monitorleads, and this mistake would be detected if there is a prolonged delaybetween rhythm analysis and the shock/no shock decision; or if they wereplaced after rhythm analysis.

Various criteria may be considered for benchmarking using the disclosedembodiments to analyze defibrillation (e.g., the application of shocks).For example, the disclosed embodiments may be utilized to determinewhether all analyses have been followed by both a rhythm andshock/no-shock decision, determine whether all shocks were preceded by arhythm analysis, whether all rhythms determinations were preceded by arhythm analysis, determine whether there are any mismatches betweenrhythm and shock decision detected, and whether pauses for rhythmanalyses have been managed appropriately. In one embodiment theseinconsistencies may be detected in the analysis process, and the user isalerted by the use of a specific symbol (such as “***”) preceding thefail comment. Clicking on the failed item then initiates an autocorrectprocess. An example of this would be not shocking a rhythm determined tobe shockable; and if a shock was actually given (and recording ofno-shock was a recording error) it can be corrected by the program to“Shock”. Such logic has been applied to may potential analysis failuresthat are flagged as a failure when indeed they represent recordingerrors.

An expected sequence of actions may be: rhythm analysis (analysis),rhythm determination (rhythm), shock/no-shock decision. Thus, shockbenchmarks may include the presence of all three actions being tested:rhythm analysis pauses without rhythms or Shocks/no-Shocks (e.g., fail:analysis @10:15:12 has no rhythm before Shock @10:15:18, fail: analysis@ 10:15:12 has no Shock after rhythm @10:15:15, fail: analysis @10:15:12has no subsequent rhythm or Shock/no-Shock), rhythms without a precedinganalysis (fail: no analysis before rhythm @10:15:12), and Shocks withouta preceding analysis (fail: no analysis before Shock @10:15:12).Subsequently, the timing of the three actions may be evaluated: Durationof rhythm analysis—managed in Pause(s), the time interval between ashockable rhythm and the Shock (pass: Decision to Shock @10:15:25 was onTime (2 sec) after a shockable rhythm (BM is 5 sec), fail: Decision toShock @10:15:25 was LATE (8 sec) after a shockable rhythm (BM is 5sec)), the time interval between a non-shockable rhythm and no shockdelivered (pass: Decision to not Shock @ 10:15:25 was on Time (2 sec)after a non-shockable rhythm (BM is 5 sec), fail: Decision to not Shock@10:15:25 was LATE (8 sec) after a non-shockable rhythm (BM is 5 sec)),and an Inappropriate rhythm-Shock/no-Shock decision (fail: shockablerhythm @ 10:15:12 was NOT shocked, fail: non-shockable rhythm @ 10:15:12WAS shocked). Because some of the fails may represent recording errors,an opportunity may be provided to correct them and then reanalyze theCode before a final analysis is performed.

Likewise, if a Chest Compressions devise, such as a LUCAS, is used,corresponding benchmarks are invoked. For example, the disclosedembodiments may be utilized to determine and analyze application (pass:LUCAS—Was Applied before Start of Recording, pass: LUCAS—Was Re-applied& Operational at 01:30, fail: LUCAS was available but never applied,fail: LUCAS application started but never completed, pass: Unable tojudge LUCAS application because Start time was not recorded, pass: LUCASwas applied in 10 sec (BM is 10 sec), fail: LUCAS was applied in 20 sec(BM is 10 sec)), failure (pass: LUCAS—failed at 00:30, pass: PresumedLUCAS failure because CC were started after LUCAS application).

A set of chest compressions (CC) (FIG. 43) may be defined as an intervalbordered by adjoining actions that begin and end compressions. Pausesand other actions/events may exist in this interval. The final set mayend by the earliest of ROSC or the End of Recording. Thus, resumption ofcardiac compressions after ROSC (lost ROSC) may be managed. Within a setof CC the following are calculated: the total time (sec) of a set, thetotal time (sec) of CC, and the total time (sec) of pauses. Likewise,the duration of the set of compressions may be benchmarked (fail: CC Set@15:08:59 was too BRIEF, lasting 29 sec (BM is 100 sec), fail: CC Set@15:08:59 was too LONG, lasting 200 sec (BM is 150 sec), pass: 90.1% ofCC were in Sets with acceptable durations (BM is 100-150 sec)).

Compressions may be considered fresh if they were done during aspecified benchmark interval (e.g., 75 seconds). Those performed afterthe benchmark 75 seconds (without switching compressors) may be deemednot Fresh. This distinction is made because the quality of continuouslyperformed compressions deteriorates after about 60-75 seconds.

Likewise, switching compressors during CC may be benchmarked (fail: CCSet starting @14:54:31 went 237 sec without a switch of compressors (BMis 75 sec), pass: 60.1% of CC were performed with fresh compressors).

The disclosed embodiments may be utilized to determine and analyze tasksregarding a patient's airway (FIG. 45). When initial airway tasks havebeen performed before the start of a Code (see pre-code sets), they maynot be benchmarked (pass: Initial Airway Maneuvers not needed).Otherwise, they may be tested against the start of recording time. Inthe benchmarks below, the word title could mean one of the following:airway patency check, OPA/NA insertion or O2 application (fail: titlewas not performed, pass: title @ 10:15:56 was On Time (200 sec afterstart of recording) (BM is 120 sec), fail: title @ 10:15:56 was LATE(200 sec after start of recording) (BM is 120 sec). If an invasiveairway fails, initial airway tasks are not retested. An invasive airway(ET or other type) is almost always needed—but occasionally it is not(such as when the patient is gasping regularly at an adequate rate or ifROSC with adequate ventilation occurred before airway would have beeninserted). Because this is rare, it is not tested in the program and canbe managed by an entry in the comment section during the archivingprocess. If a Code protocol uses CCR, the initial rhythm may be used inthe benchmarking process. It that rhythm is shockable, invasive airwayinsertion is delayed for 3 CC “cycles” or approximately 6 minutes.Therefore, no benchmarking may be possible if no rhythm was recorded,the Code ended before a first rhythm was recorded, or ROSC occurredbefore a first rhythm was recorded. All of this logic may not apply ifresponders were performing CPR. In accordance with at least onedisclosed embodiment, an assumption may be made that a responder whostarts with CPR (a pre-code decision) does not switch to CCR during theCode.

As part of the airway tasks benchmarked (FIG. 45), invasive airwayfailure is tested (if it did NOT occur: pass: failure of invasiveairway—did NOT occur, if it DID occur: pass: failure of invasiveairway—RETRY was attempted, fail: failure of invasive airway—NO RETRYwas attempted). Invasive airway insertion may not be tested (passinvasive airway: invasive airway—N/A (done before start of recording),pass: invasive airway—N/A (not doing CCR), pass: invasive airway—N/A (noInitial rhythm detected), pass: invasive airway not needed—ROSC or Endof Code occurred). Alternatively, invasive airway insertion may betested. In some of results, the actual name of the invasive airway (ET,Combitube, etc.) may be used; thus, the term title may be replaced bythat name (fail: no invasive airway was Started and One was needed). Itis determined, whether an invasive airway, when using CCR, has beeninserted before a rhythm is analyzed (fail: title was Started BEFORErhythm analysis done), if the initial rhythm was not shockable (pass:title Insertion @10:15:25 was On Time (15 sec) after an initiallynon-shockable rhythm (BM is 30 sec), fail: title Insertion @ 10:15:25was late (45 sec) after an initially non-shockable rhythm (BM is 30sec)), if an initial rhythm was shockable (fail: title Insertion @10:15:25 was too EARLY (200 sec) after an initially shockable rhythm (BMis 360-390 sec), fail: title Insertion @ 10:15:25 was too LATE (400 sec)after an initially shockable rhythm (BM is 360-390 sec), pass: titleInsertion @ 10:15:25 was too EARLY (370 sec) after an initiallyshockable rhythm (BM is 360-390 sec)).

The disclosed embodiments may be utilized to determine and analyze theuse of end tidal CO2 test; however, these may be tested only if such atest is in a relevant protocol (which is a pre-code issue). For example,the test may not be in the protocol (pass: etCO2—NOT in protocol), maynot be tested if etCO2 was applied before the start of CodeRecordation(pass: etCO2 in place Before recording started), or may notbe tested if no invasive airway was inserted (pass: etCO2 not needed—noinvasive airway inserted). A recording error warning may be generated ifetCO2 use is recorded but no airway insertion is recorded (fail: ***etCO2 used but NO invasive airway insertion recorded ***) (where the ***indicate an auto-correction is available—in this example it would fixthe failure by recording an invasive airway insertion with anappropriate time stamp). Likewise, an error may occur if etCO2 is in therelevant protocol but detection device(s) are not available (fail:etCO2—IN protocol but neither Main- or Side-Stream available).

If detection devices were available and an invasive airway was used(title refers to name of invasive airway device), the disclosedembodiment may detect various recording errors (premature etCO2 use onlyapplies if only Mainstream is used; fail: *** etCO2 used but NO invasiveairway insertion recorded ***; or fail: *** Mainstream etCO2 start @10:25:12 was BEFORE airway insertion @ 10:25:30 ***). However, thedisclosed embodiments may also detect and analyze if etCO2 was not used(fail: Mainstream etCO2 was available but NEVER used after titleinsertion @ 10:15:25, fail: Sidestream etCO2 was available but NEVERused). Similarly, detection and analysis of whether sidestream etCO2 wasused (fail: Sidestream etCO2 start @ 10:25:12 was LATE (100 sec) afterstart of recording (BM is 30 sec), pass: Sidestream etCO2 start @10:25:12 was on Time (20 sec) after start of recording (BM is 30 sec)),and/or mainstream was used (timing can only be tested if Sidestream notavailable: pass: Mainstream etCO2 @ 10:25:15 started On Time (15 sec)after Airway @10:25:00 (BM is 20 sec), and fail: Mainstream etCO2 @10:25:45 started LATE (45 sec) after Airway @ 10:25:00 (BM is 20 sec)

The disclosed embodiments may be utilized to determine theappropriateness of pausing CC for various recorded reasons. One exampleof such a pause is that for checking a pulse; which should never beperformed if etCO2 is available (even it not used). The duration ofpauses for pulse checks may be managed using functionality provided byat least one of the screens provided in the GUI. If etCO2 is operational(defined as the interval(s) between etCO2 applications and adjoiningfailures). Disclosed embodiments may be utilized to determine andanalyze if no pulse check done (pass: etCO2—Used and NO pulse checksdone) and pulse check(s) done and etCO2 operational (fail: etCO2—PulseCheck @00:20 is NOT ACCEPTABLE—etCO2 was available)

The disclosed embodiments may be utilized to determine and analyzeperformance of IV/IO tasks (FIG. 46). For example, whether they werestarted in time, the time spent inserting IV/IO (from “Start” to “Done”)and whether an IV was attempted or re-attempted prior to attempting tostart an IO.

Similarly, the disclosed embodiments may be utilized to determine andanalyze the application of drugs (FIG. 47) including the timing of afirst dose in relation to a preceding activity, whether and when repeatdoses were given, and whether AHA standards were used when timing theuse of Amiodarone given after shockable rhythms were detected. Forexample, if a drug is indicated only after a specific action and it isadministered before that action, a fail is generated (e.g. Amiodaroneuse is dependent upon the presence of a shockable rhythm).

It should be understood that protocols sets, if used, define a number ofissues that are used in benchmarking drug usage. The application ofspecific drugs is only tested as part of benchmarking if they are in aprotocol being used. For example, certain drugs may not be within aprotocol, e.g., Vasopressin, Amiodarone, or Epinephrine.

In accordance with at least one embodiment, only IV drugs may berecorded; thus, grid show-hide logic for such an embodiment may onlydisplay drugs when an IV or IO is operational.

In particular, when determining and analyzing administration ofEpinephrine (Epi), various parameters may be analyzed for benchmarking,including whether Epi was in protocol and indicated but not given, aninterval between the first Epi dose and when an IV or IO wasoperational, determining the number of actual and expected Epi doses andtheir timing. Similarly, the timing of one or more doses of Amiodaroneis determined and analyzed in relationship to AHA standards (if they areused) on administration in relationship to detection of a persistent orrecurrent shockable rhythm. Similar analysis may be performed forVasopressin.

Additionally, disclosed embodiments may be used to determine and analyzewhether specific drugs were administered that almost always should notbe given during a Code, e.g., Atropine, Bicarb or Calcium.

In accordance with disclosed embodiments, the timing and length ofvarious pauses (FIG. 48) may be benchmarked including those associatedwith, for example, Endotracheal tube (ET) insertion, rhythm analysis,application of defibrillation pads, ventilation of the patient, chargingthe defibrillator, pulse checks, resuming CC after a shock/no-shockdecision, peeking at rhythm, switching chest compressors, application ofan automatic compression device, etc. For each of the pauses analyzed,various details are recorded for analysis including the number of timesthey occurred during the Code, the total of acceptable seconds—theportion of pauses seconds within the benchmark interval, and the totalof unnecessary seconds—the portion that exceeded the benchmark interval.

Various pre-code issues may be utilized in the analysis of some pauses,as shown in Table 4.

TABLE 4 Pause Type of CPR Type of Defibrillator Use of Type CPR CCR AEDManual etCO2 to insert ET X X — — — To apply Pads X X — — — ForVentilation(s) X X — — — To Charge(s) X X X — — defibrillator Other(s) —— — — — For Pulse Check(s) X X — — X For Rhythm Analyses — — X X — (?Need shock or not)

The disclosed embodiments may be utilized to determine and analyzeperformance (e.g., whether it occurred and its timing) of ET insertion,rhythm analysis, application of pads, ventilation, defibrillatorcharging, pulse checks, the use of automatic chest compressions devices,etc. In accordance with at least one disclosed embodiment, eachbenchmark may be categorized (and displayed on the GUI or output in oneor more reports) according to a corresponding category, e.g., the McMAIDcategory illustrated in Tables 5-9.

TABLE 5 Sec Metronome 15 Metronome - To Start after Starting CC 15Metronome - To Start after Starting CC

TABLE 6 Sec Compressions 8 Start CC - after Prior Rhythm detected 20Start CC - after Start of Recording 75 CC - Time between SwitchingCompressors 100 CC - Duration - Min 150 CC - Duration - Max 20 StartCC - after Prior Rhythm Analysis - AED 3 Start CC - after PriorShock/NoShock 8 Start CC - after Prior Rhythm Analysis - Manual 8 StartCC - after Prior Rhythm detected 8 Start CC - after Prior RhythmAnalysis - Manual 20 Start CC - after Prior Rhythm Analysis - AED 20Start CC - after Start of Recording 3 Start CC - after PriorShock/NoShock 150 CC - Duration - Max 75 CC - Time between SwitchingCompressors 100 CC - Duration - Min

TABLE 7 Sec Monitor 10 To Charge - using Manual defibrillator 0 ToCharge - using CCR & Manual defibrillator 10 To Charge - using Manualdefibrillator 10 To Analyze Rhythm - AED 10 Pads - To apply - doing CPR10 Pads - To apply - doing CPR 15 To Charge - using AED 5 Pads - Toapply - doing CCR 5 To Analyze Rhythm - Manual defibrillator 5 ToShock - after Rhythm Analysis 10 To Analyze Rhythm - AED 30 Monitor - ToTurn on after it's available 5 To Shock - after Rhythm Analysis 5 Pads -To apply - doing CCR 5 To Analyze Rhythm - Manual defibrillator 3 ToShock - after shockable Rhythm 15 To Charge - using AED 3 To Shock -after shockable Rhythm 30 Monitor - To Turn on after it's available 0 ToCharge - using CCR & Manual defibrillator

TABLE 8 Sec Airway 0 To Ventilate if doing CCR 30 Max Time afterInitially nonSockable to Start ET 60 Start Sidestream etCO2 - afterStart of Recording 120 Initial Airway - after Start of Recording 360Invasive airway - Earliest time after Initial Rhythm - shockable 360Invasive airway - Earliest time after Initial Rhythm - shockable 120Initial Airway - after Start CC 390 Invasive airway - Latest time afterInitial Rhythm - shockable 390 Invasive airway - Latest time afterInitial Rhythm - shockable 0 To Ventilate if doing CCR 30 Max Time afterInitially nonSockable to Start ET 30 Invasive airway - Max time afterInitial Rhythm - non-shockable 15 Start Mainstream etCO2 - afterInvasive airway ready 120 Initial Airway - after Start of Recording 30Invasive airway - Max time after Initial Rhythm - non-shockable 5 ToVentilate if doing CPR 5 To Ventilate if doing CPR 120 Initial Airway -after Start CC 15 Start Mainstream etCO2 - after Invasive airway ready60 Start Sidestream etCO2 - after Start of Recording IV_IO 3 Max # ofEpi doses allowed 3 Max # of Epi doses allowed 20 Max time to Insert IO20 Max time to Insert IV 20 Max time to Insert IO 20 Max time to InsertIV

TABLE 9 Sec Drugs 15 Max time 1st dose Epi after IV or IO ready 30 Maxtime between 1st Epi and 1st Vasopressin 540 Min time between 2nd and1st Vasopressin doses 180 Min time between Epi doses 300 Max timebetween Epi doses 660 Max time between 2nd and 1st Vasopressin doses 660Max time between 2nd and 1st Vasopressin doses 15 Max time 1st dose Epiafter IV or IO ready 30 Max time between 1st Epi and 1st Vasopressin 540Min time between 2nd and 1st Vasopressin doses

The following example (Table 10) provides additional informationdetailing all events recorded during a code and their timing. Thedisplay of timing can be the interval from the start of the code or itcan be adjusted to display real time if the time the code started isavailable. If the Code has been saved (archived), a report header forthe Code may contain various information such as who the Recorder,physician, nursing staff and other personnel involved in the Code, theactual time the Code began (Real and Run Report Codes), where the Codeoccurred, date of the Code, and type of Code. Only some of this data maybe available for preliminary analyses.

TABLE 10 Clock Real Time Action 00:00 00:00:00 Crash Cart present beforeStart of Recording 00:00 00:00:00 Crash Cart Arrived 00:00 00:00:00Doing CCR (not CPR) 00:00 00:00:00 Using Manual Defibrillator 00:0000:00:00 Start of Recording 01:31 00:01:31 Pads on @ start of recording01:31 00:01:31 Start CC 01:56 00:01:56 Monitor Here 01:56 00:01:56Monitor Turned On 03:09 00:03:09 Analyze Rhythm 03:15 00:03:15 shockableRhythm 03:17 00:03:17 Resume after Shock 03:22 00:03:22 SAME person05:24 00:05:24 shockable Rhythm 05:24 00:05:24 Analyze Rhythm 05:2600:05:26 Resume after Shock 05:28 00:05:28 Switch CC 07:28 00:07:28Analyze Rhythm 07:28 00:07:28 shockable Rhythm 07:31 00:07:31 Resumeafter Shock 07:34 00:07:34 Switch CC 08:00 00:08:00 IV Retry 09:0800:09:08 Epinephrine 09:33 00:09:33 Analyze Rhythm 09:33 00:09:33shockable Rhythm 09:35 00:09:35 Resume after Shock 10:03 00:10:03 SwitchCC 10:13 00:10:13 Peek at Rhythm 10:24 00:10:24 Switch CC 10:54 00:10:54Pulse Check 10:56 00:10:56 SAME person 11:34 00:11:34 Analyze Rhythm11:35 00:11:35 shockable Rhythm 11:36 00:11:36 Resume after Shock 11:4400:11:44 Switch CC 12:13 00:12:13 for Other Reason 12:16 00:12:16 SAMEperson 13:32 00:13:32 Analyze Rhythm 13:32 00:13:32 shockable Rhythm13:34 00:13:34 Resume after Shock 13:37 00:13:37 Switch CC 13:4300:13:43 Peek at Rhythm 13:49 00:13:49 Switch CC 14:00 00:14:00 Start IO14:00 00:14:00 IO Operational 14:00 00:14:00 Amiodarone 300 mg bolus14:30 00:14:30 for Other Reason 14:31 00:14:31 SAME person 15:1900:15:19 for Other Reason 15:21 00:15:21 Switch CC 15:34 00:15:34Analyze Rhythm 15:35 00:15:35 shockable Rhythm 15:38 00:15:38 Resumeafter Shock 15:59 00:15:59 Switch CC 16:00 00:16:00 ROSC 16:26 00:16:26for Other Reason 16:28 00:16:28 SAME person 17:34 00:17:34 ROSC 17:3500:17:35 Analyze Rhythm 17:39 00:17:39 non-shockable 18:00 00:18:00 IVfailed 18:00 00:18:00 IV Retry 18:00 00:18:00 IV operational 19:0000:19:00 Amiodarone 150 mg bolus 19:00 00:19:00 Other Drug 19:1000:19:10 End of Code

Thus, in one example, the results of benchmarking analysis may bearranged by pass/fail and within these two categories by, for example,McMAID order, as shown in Tables 11-12.

TABLE 11 Passed Compressions 60.1% of CC were performed with “Fresh”Compressors 90.1% of CC were in Sets with acceptable durations (BM of100-150″) Monitor Pad application - Occurred BEFORE 1st Rhythm AnalysisCrash Cart - Present before start of recording Decision to @15:10:39 wasOn Time (−1059″) after a non-shockable Rhythm (BM is3″) Decision toShock @14:56:15 was On Time (2″) after a shockable Rhythm (BM is3″)Decision to Shock @14:58:24 was On Time (2″) after a shockable Rhythm(BM is3″) Decision to Shock @15:00:28 was On Time (3″) after a shockableRhythm (BM is3″) Decision to Shock @15:02:33 was On Time (2″) after ashockable Rhythm (BM is3″) Decision to Shock @15:04:35 was On Time (1″)after a shockable Rhythm (BM is3″) Decision to Shock @15:06:32 was OnTime (2″) after a shockable Rhythm (BM is3″) Monitor - On 0″ afteravailable (BM is 30″) Decision to Shock @15:08:35 was On Time (3″) aftera shockable Rhythm (BM is3″) Airway Failure of Invasive Airway - Did NOToccur etCO2 not needed - no invasive airway inserted Drugs Amiodarone -2nd Dose was 150 mg Amiodarone - 1st Dose was 300 mg Pauses no pausesfor ET Insertion occurred no pauses for Ventilations occurred no pausesfor Apply LUCAS occurred no pauses for Charging occurred no pauses forApplying Pads occurred

TABLE 12 Failed Metronome Metronome - was NOT Used Compressions CC Set@15:08:59 was too BRIEF, lasting 29″ (BM is 100″) CC Set starting@14:54:31 went 237″ without a Switch of Compressors (BM is 75″) LUCASwas available but never applied CC Set starting @15:06:49 went 92″without a Switch of Compressors (BM is 75″) CC Set starting @15:04:44went 113″ without a Switch of Compressors (BM is 75″) CC Set starting@15:03:24 went 80″ without a Switch of Compressors (BM is 75″) CC Setstarting @15:00:34 went 149″ without a Switch of Compressors (BM is 75″)CC Set @15:09:28 was too BRIEF, lasting 66″ (BM is 100″) CC Set starting@14:58:28 went 126″ without a Switch of Compressors (BM is 75″) Monitorno Analysis before rhythm @14:58:24 no Analysis before rhythm @15:06:32no Shock after Rhythm @15:10:39 Airway O2 Application was not performedno Invasive Airway was Started and One was needed Airway Patency Checkwas not performed OPA/NPA insertion was not performed IV-IO IV Retry@15:01:00 was BEFORE IO attempt @15:07:00 IV/IO - Neither IV or IOattempted Drugs There were 112″ between ROSC and last Epi @15:02:08where a repeat dose was indicated 1dose of Epi was given after IOCompleted - too MANY (BM is 0-0 doses) Amiodarone - 1st dose @15:07:00was 615″ LATE (after 1st shockable rhythm) (BM is 30″) Amiodarone - 2nddose @ 15:12:00 was 786″ LATE (after 2nd shockable rhythm) (BM is 30″)Pauses for Other Reason Pauses - All (8″) were NOT necessary Peek atRhythm Pauses - All (17″) were NOT necessary 71% of 7 Resume CC afterShock/noShock pauses (50 of 70″) were NOT necessary 11% of 8 AnalyzeRhythm pauses (3 of 27″) were NOT necessary Pulse Check Pause - All (2″)were NOT necessary Details of All Pauses that occurred during the Code

In accordance with at least one disclosed embodiment (FIG. 49), thetotal number of pauses for a given type of pause may be calculated aswell as the total seconds that pauses took away from chest compressions.Similarly, some pauses may be acceptable, but only up to a benchmarkedlimit, and pauses that exceed that limit may be considered unacceptable.Likewise, the duration of the Code, i.e., from beginning of recording tothe earliest of Return Of Spontaneous Circulation (ROSC) (sustained) orthe end of recording may be documented. This allows computation of thepercent of time spent doing chest compressions in two scenarios: actualand ideal if unnecessary pauses were eliminated). This is very relevantbecause unnecessary time not doing compressions is known to decreasesurvival.

Thus, it should be understood that the Code recordation, documentationand analysis provided in accordance with the disclosed embodiments isvaried and far reaching. A point that must be emphasized is that anobjective analysis of a code is available for review by the members ofthe resuscitation team or trainee as soon as the code is completed. Alldata generated during cardiac arrest events may also be archived so asto be stored in a meaningful and accessible way for subsequent review ata later date. The information relevant to the type of Code (e.g.physician and registered nurse in charge, UtStein information, etc.) maybe collected and stored and that information may be used to sort thearchived data. In this way, the data is generated in real time during acardiac arrest event and is accessible and comparable with data fromother events that share common characteristics. Moreover, the disclosedembodiments enable the ability to judge, monitor, track and document theefficacy of certain drugs, treatment protocols, individuals, teams ofpersonnel, equipment, and timing of tasks performed during a Code in amore objective manner using documented benchmarking.

While this invention has been described in conjunction with the specificembodiments outlined above, it is evident that many alternatives,modifications and variations will be apparent to those skilled in theart. Accordingly, the various embodiments of the invention, as set forthabove, are intended to be illustrative, not limiting. Various changesmay be made without departing from the spirit and scope of the invention

For example, as explained above, the description of the system,equipment and methodology provided herein is merely exemplary and is notlimiting. Thus, it should be understood that the disclosed embodimentsmay be functional to perform recordation, analysis, feedback, training,and post event processing without reference to, or use of, protocol orpre-code data because there are other ways of implementing thefunctionality beyond the implementation provided by the code included inthe Appendix.

Additionally, it should be understood that the functionality describedin connection with various described components of various inventionembodiments may be combined or separated from one another in such a waythat the architecture of the invention is somewhat different than whatis expressly disclosed herein. Moreover, it should be understood that,unless otherwise specified, there is no essential requirement thatmethodology operations be performed in the illustrated order; therefore,one of ordinary skill in the art would recognize that some operationsmay be performed in one or more alternative order and/or simultaneously.

Various components of the invention may be provided in alternativecombinations operated by, under the control of or on the behalf ofvarious different entities or individuals.

Further, it should be understood that, in accordance with at least oneembodiment of the invention, system components may be implementedtogether or separately and there may be one or more of any or all of thedisclosed system components. Further, system components may be eitherdedicated systems or such functionality may be implemented as virtualsystems implemented on general purpose equipment via softwareimplementations.

As a result, it will be apparent for those skilled in the art that theillustrative embodiments described are only examples and that variousmodifications can be made within the scope of the invention as definedin the appended claims.

What is claimed is:
 1. A system for recording and documenting tasksperformed during the treatment of a cardiac arrest event, the systemcomprising: at least one computer processor running software code thatcontrols display of a plurality of icons on a graphical user interface;at least one memory storing the software code; and at least one memorystoring data generated as a result of a recording user's interactionwith the plurality of icons on the graphical user interface, wherein thegraphical user interface includes a plurality of screens that includethe plurality of icons, and information regarding the tasks is inputfrom the user via a code recordation screen that is one of the pluralityof screens, and wherein a subset of the plurality of icons is displayedon the code recordation screen depending on information previously inputfrom the user via the code recordation screen.
 2. The system of claim 1,wherein, the plurality of screens includes a code development screenthat includes a plurality of icons provided on the graphical userinterface that enables an administrative user to develop a Code used torecord and document tasks performed during the treatment of cardiacarrest events.
 3. The system of claim 2, wherein the Code is one of aRun Report Code, a Mock Code, a Training Code and a Real Code.
 4. Thesystem of claim 1, further comprising a speaker and microphone, whereinthe processor also runs software code that controls receiving inputfrom, and providing output to, the recording user.
 5. The system ofclaim 1, further comprising a speaker and microphone, wherein theprocessor also runs software code that controls receiving audio inputfrom, and providing audio output to, individuals involved in thetreatment of the cardiac arrest event.
 6. The system of claim 1, whereinthe software code running on the at least one computer processoranalyzes generated data and compares the generated data againstbenchmark data.
 7. The system of claim 1, wherein the software codeincludes show-hide logic that removes icons pertaining to a particulartask one that task has been performed.
 8. The system of claim 1, whereina time stamp is generated for task data input into the system and thetime stamp and the task data are stored in memory.
 9. The system ofclaim 1, wherein the system includes a computer interface that displaysthe graphical user interface on a touch screen, wherein the selection ofthe plurality of icons results from touching the plurality of icons onthe touch screen.
 10. The system of claim 1, wherein the system iscoupled to a post-event data processing system that analyzes the datagenerated by the system to identify what inventory was used during thetreatment of the cardiac arrest event.
 11. The system of claim 10,wherein the inventory includes drugs and equipment used during thetreatment of the cardiac arrest event.
 12. The system of claim 1,wherein the system is coupled to a post-event data processing systemthat analyzes the data generated by the system to identify costsassociated with the treatment of the cardiac arrest event.
 13. Thesystem of claim 1, wherein the data generated by the system is output inat least one report that includes an indication of tasks performedduring the treatment of the cardiac arrest event and timing of thosetasks.
 14. The system of claim 1, wherein the data generated by thesystem is output to at least one screen or the plurality of screens thatincludes an indication of tasks performed during the treatment of thecardiac arrest event and timing of those tasks.
 15. A method forproviding a system for recording and documenting tasks performed duringthe treatment of a cardiac arrest event, the method comprising:providing at least one computer processor running software code thatcontrols display of a plurality of icons on a graphical user interface,wherein the software code is stored in at least one memory; and storingdata generated as a result of a recording user's interaction with theplurality of icons on the graphical user interface in at least onememory; wherein the graphical user interface includes a plurality ofscreens that include the plurality of icons, and information regardingthe tasks is input from the user via a code recordation screen that isone of the plurality of screens, and wherein a subset of the pluralityof icons is displayed on the code recordation screen depending oninformation previously input from the user via the code recordationscreen.
 16. The method of claim 15, wherein, the plurality of screensincludes a code development screen that includes a plurality of iconsprovided on the graphical user interface that enables an administrativeuser to develop a Code used to record and document tasks performedduring the treatment of cardiac arrest events.
 17. The method of claim16, wherein the Code is one of a Run Report Code, a Mock Code, aTraining Code and a Real Code.
 18. The method of claim 15, furthercomprising providing a speaker and microphone, wherein the processoralso runs software code that controls receiving input from, andproviding output to, the recording user.
 19. The method of claim 15,further comprising providing a speaker and microphone, wherein theprocessor also runs software code that controls receiving audio inputfrom, and providing audio output to, individuals involved in thetreatment of the cardiac arrest event.
 20. The method of claim 15,further comprising the software code running on the at least onecomputer processor analyzing generated data and comparing the generateddata against benchmark data.
 21. The method of claim 15, wherein thesoftware code includes show-hide logic that removes icons pertaining toa particular task one that task has been performed.
 22. The method ofclaim 15, wherein a time stamp is generated for task data input into thesystem and the time stamp and the task data are stored in memory. 23.The method of claim 15, wherein the system includes a computer interfacethat displays the graphical user interface on a touch screen, whereinthe selection of the plurality of icons results from touching theplurality of icons on the touch screen.
 24. The method of claim 15,wherein the system is coupled to a post-event data processing systemthat analyzes the data generated by the system to identify whatinventory was used during the treatment of the cardiac arrest event. 25.The method of claim 24, wherein the inventory includes drugs andequipment used during the treatment of the cardiac arrest event.
 26. Themethod of claim 15, wherein the system is coupled to a post-event dataprocessing system that analyzes the data generated by the system toidentify costs associated with the treatment of the cardiac arrestevent.
 27. The method of claim 15, wherein the data generated by thesystem is output in at least one report that includes an indication oftasks performed during the treatment of the cardiac arrest event andtiming of those tasks.
 28. The method of claim 15, wherein the datagenerated by the system is output to at least one screen or theplurality of screens that includes an indication of tasks performedduring the treatment of the cardiac arrest event and timing of thosetasks.
 29. A computer readable medium including software code, which,when executed by a computer processor, performs operations comprising:controlling display of a plurality of icons on a graphical userinterface using the at least one computer processor, wherein thesoftware code is stored in at least one memory; and storing datagenerated as a result of a recording user's interaction with theplurality of icons on the graphical user interface in at least onememory; wherein the graphical user interface includes a plurality ofscreens that include the plurality of icons, and information regardingthe tasks is input from the user via a code recordation screen that isone of the plurality of screens, and wherein a subset of the pluralityof icons is displayed on the code recordation screen depending oninformation previously input from the user via the code recordationscreen.
 30. The computer readable medium of claim 29, wherein, theplurality of screens includes a code development screen that includes aplurality of icons provided on the graphical user interface that enablesan administrative user to develop a Code used to record and documenttasks performed during the treatment of cardiac arrest events.
 31. Thecomputer readable medium of claim 29, wherein the Code is one of a RunReport Code, a Mock Code, a Training Code and a Real Code.
 32. Thecomputer readable medium of claim 29 wherein the at least one computerprocessor also runs software code that controls receiving audio inputfrom, and providing audio output to, individuals involved in thetreatment of the cardiac arrest event.
 33. The computer readable mediumof claim 29, further comprising the software code running on the atleast one computer processor analyzing generated data and comparing thegenerated data against benchmark data.
 34. The computer readable mediumof claim 29, wherein the software code includes show-hide logic thatremoves icons pertaining to a particular task one that task has beenperformed.
 35. The computer readable medium of claim 29, wherein a timestamp is generated for task data input into the system and the timestamp and the task data are stored in memory.
 36. The computer readablemedium of claim 29, further comprising analyzing the data generated bythe system to identify what inventory was used during the treatment ofthe cardiac arrest event.
 37. The computer readable medium of claim 36,wherein the inventory includes drugs and equipment used during thetreatment of the cardiac arrest event.
 38. The computer readable mediumof claim 29, further comprising analyzing, using a post-event dataprocessing system, the data generated by the system to identify costsassociated with the treatment of the cardiac arrest event.
 39. Thecomputer readable medium of claim 29, wherein the data generated by thesystem is output in at least one report that includes an indication oftasks performed during the treatment of the cardiac arrest event andtiming of those tasks.
 40. The computer readable medium of claim 29,wherein the data generated by the system is output to at least onescreen or the plurality of screens that includes an indication of tasksperformed during the treatment of the cardiac arrest event and timing ofthose tasks.